On 18/08/14 14:24, Florent Daigniere wrote: > On Mon, 2014-08-18 at 14:04 +0100, Matthew Toseland wrote: >> On 17/08/14 18:24, unixninja92 wrote: >>> Hi all, >>> >>> I've gotten a lot done since my last status update. The deadline for >>> GSoC is tomorrow, and I'm just about done. All I need to do is finish >>> up writing unit tests for ERAT (like 3 more to go) and CryptBucket. I >>> also need to write docs for ERAT and CryptSignature, but that should >>> not take very long. >>> >>> This means that all the other classes I've written for the API are >>> finished and ready for review/merging. This includes: CryptByteBuffer >>> (used to be called CryptBitSet), Hash, KeyExchange, KeyGenUtils, >>> MessageAuthCode, and MasterSecret. I've submitted a pull request (#277 >>> [1]) for EncryptedRandomAccessThing and it's dependencies so that toad >>> can start working with it as soon as possible. This includes >>> CryptByteBuffer, KeyGenUtils, MasterSecret, and MessageAuthCode. >>> CryptByteBuffer and MessageAuthCode have not had any review yet, so >>> please review! >>> >>> Hash has been submitted in PR #258 [2]. Once #277 has been merged I >>> will submit a new pull request that will include KeyExchange, >>> CryptBucket and CryptSignature. >>> >>> Unfortunately I don't have time to get JFKExchange classes working as >>> part of GSoC, but I will hopefully have time to work on them in the >>> future. >>> >>> So please review #277 and #271(upgrade to BC 1.51)[3] :) >>> >>> -Charles >>> >>> [1] https://github.com/freenet/fred/pull/277 >>> [2] https://github.com/freenet/fred/pull/258 >>> [3] https://github.com/freenet/fred/pull/271 >> For purge-db4o (new client layer), I need a common API for both simple >> checksums (CRC32 at the moment) and HMAC's. I have implemented an API >> and a bunch of tools (ChecksumChecker), but will your API support this >> more cleanly? > Doh! > > The remit of his GSoC is to work on a crypto API... what you're > describing is not crypto related. In his crypto api, there will be a > tool to do MACs which might use HMAC as the underlying primitive... but > no, don't even think about adding CRC32 to it! Okay, to summarize a rather long discussion:
The new splitfile code uses CRC32 checksums to check for data corruption in relatively small chunks of data stored on disk, representing e.g. the status of a segment. Freenet provides the ability to password-encrypt downloads. This provides some limited protection, if there is a strong enough password, if the computer is stolen/seized. It does not provide any protection if the computer is tampered with covertly between the owner using it. Hence there is no need to use a stronger HMAC to protect downloaded data, even if it is encrypted. In the long run we should consider whether to keep on supporting disk crypto. The usual argument against is that it contradicts the unix philosophy; the reason we provide it is that physical attacks, e.g. seizing somebody's computer, are the most common in practice, especially in hostile regimes, and people who install Freenet may not necessarily want to install full disk encryption before using it, or have the expertise. However, there are secure linux distributions, and nowadays (even if we fix the key generation function), a strong enough password would need to be very long. This is possible but it is a lot of effort. The users who are willing to use a long password are probably also the users who are willing to do full disk encryption and/or use Tails or whatever. See bugs: https://bugs.freenetproject.org/view.php?id=6292 https://bugs.freenetproject.org/view.php?id=6293 https://bugs.freenetproject.org/view.php?id=6294 For now I will proceed with the splitfile code on the assumption that we keep the same threat model etc, with the same cheap CRC checksums (and other verification code), and using unixninja's EncryptedRandomAccessThing when temporary file encryption is enabled (i.e. physical security level is LOW or higher).
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
