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? > > > > 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.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
