On Thu, Sep 12, 2013 at 7:06 AM, Julien Vehent <jul...@linuxwall.info> wrote: > It seems that AES-256 is always 25% to 30% slower than AES-128, regardless of > AES-NI, or the CPU family.
> The slowest implementation of AES-256 has a bandwidth of 21MBytes/s, which is > probably fast enough for any browser > If performance was the only reason to prefer AES-128, I would disagree with > the proposal. But your other arguments regarding AES-256 not > provided additional security, are convincing. > This paper: eprint.iacr.org/2007/318.pdf > On the complexity of side-channel attacks on AES-256 > - methodology and quantitative results on cache attacks - Perhaps my arguments were a little over-stated though. The attack I referenced in the proposal is the related-key attack on reduced-round AES-256. That is something I should have emphasized. Really, I am speculating that this shows that thinking AES-256 is hugely more secure than AES-128 is questionable, but it isn't a slam-dunk case. The side-channel attack paper you cited seems like the more interesting one. It doesn't seem like an argument against AES-256 on its own though, since it still says AES-256 is more difficult to attack through the given side channels than AES-128. So, the main remaining question with AES-256 vs. AES-128 is not whether AES-128 is just as secure as AES-256. Instead, we have to decide whether AES-256 a better security/performance trade-off vs AES-128. I agree with you that the performance numbers for AES-256 vs. AES-128 do not make this a slam-dunk. We should do the measurements on a typical Firefox OS device and see if there is a significant difference there. Until then, unless others suggest otherwise, I think I will just keep the relative ordering of analogous AES-256 and AES-128 cipher suites the same as they are in NSS today. > However, it refers to software implementations of AES. Do we know if this > result still applies for AESNI? One takeaway from your email is that with AES-NI I don't see a strong case for prefering AES-128 over AES-256. The issue is really what to do about the non-AES-NI case, assuming we all agree that the presence of AES-NI shouldn't affect the order that the client suggests cipher suites in. Thank you very much for taking the time to do these measurements and sharing your insight. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
