On 18/04/13 13:08, Matthew Toseland wrote: > On Thursday 18 Apr 2013 07:34:28 Florent Daigniere wrote: >> On Wed, Apr 17, 2013 at 11:59:16PM +0100, Ximin Luo wrote: >>> OCB mode[1] is a CCA-secure[2] mode of encryption which means that it's >>> secure against active attackers, which pretty much applies to anything on >>> the internet. By contrast, non-authenticated encryption (anything without a >>> MAC, e.g. AES-CBC, AES-CTR) is only CPA-secure[3] and breaks under an >>> active attacker. >>> >>> You can build CCA-secure schemes by combining Enc() and Mac() operations >>> (with different keys!). Enc(M)||Mac(Enc(M)) is generally secure; >>> Enc(M||Mac(M)) and Enc(M)||Mac(M) can have security problems, the latter >>> being more likely to be insecure. >>> >>> However, OCB is apparently faster than schemes that do >>> authentication/encryption separately. It used to be patent-encumbered, but >>> as of January 2013, the creator is giving an exception to open source >>> projects.[4] > > It's essentially an adapted form of CBC. (Which means it's vulnerable to weak > IVs, but that's not a big deal). So effectively it encrypts every block > twice, as opposed to taking an HMAC at the end (= one hash of the whole > packet and then one single block hash). Is hashing that much slower than > crypto?
OCB uses the underlying block cipher *once* for each block of plaintext, whereas encrypt/mac combination schemes use it twice. >>> >>> I'm not sure if any of this was taken into consideration by whoever >>> originally did the crypto for Freenet, and I haven't looked into the >>> implementation in great detail to see if we are doing >>> Enc_k1(M)||Mac_k2(Enc(M)) everywhere, as opposed to one of the other less >>> secure options. Hopefully someone who did the crypto for freenet can >>> comment further. >>> >> >> Most of the crypto is being changed or has changed recently. >> >> - handshaking: we are doing encrypt-then-mac in the handshake. >> - link-layer: we are doing the wrong thing and apparently we're not even >> MACing everything. This needs to change (and will), but too many people have >> been involved on that part of the code concurrently for anything to happen. >> We have gsoc-work to merge and the handshaking to finish before we do >> anything with it. > > I don't follow. Packets are encrypted then HMAC'ed (and yes, this includes > everything, including the unique packet number). The obvious problems are: > 1) We use 256-bit block size for Rijndael, not 128, so it's not AES. > 2) We generate the IV from another key. IMHO this is okay; it's guaranteed to > be unique and it's not predictable unless you bust the handshake, in which > case you can read everything anyway. > 3) We use PCFB. This is iffy. IMHO we should use CTR, which might eliminate > the need for a generated IV too. Stream modes are tempting because they > provide exactly the amount of ciphertext you want; this makes life easier as > well as avoiding padding oracles (which aren't an issue if you HMAC after > encryption anyway). > 4) We truncate the HMAC to 10 bytes. This is fairly arbitrary. Authenticated > modes have one big advantage: They tell you how long a MAC you need for > adequate security given a particular packet size and volume of data between > rekeying. > >> - content-wise: we do both encrypt then mac (routing key) and encrypt and >> mac (private key) ... that's CHKs by definition. For SSKs things are a bit >> more complicated and will change soon too (we're going to switch to ECDSA) >> ... >> >> I'm all for using OCB; even though it's not a JCA standardized mode. > > Meaning we will need to use Bouncycastle? On x86 there's no point using > native code via JCA for symmetric crypto sadly. On e.g. ARM it might still be > worth having the option. The big performance gain from native code is with > ECC. > > > > _______________________________________________ > Devl mailing list > [email protected] > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
