On Mon, Oct 7, 2013 at 4:50 PM, Brian Smith <br...@briansmith.org> wrote:
> 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. > Hi Brian, all, Related-key attacks are irrelevant to TLS or any standard use of a block cipher. Side-channel attacks against AES just have to recover subkeys from a round or two, so it's not surprising that the difference between 10-round AES128 and 14-round AES256 doesn't make much of a difference. Against non-side-channel cryptanalysis of TLS ciphertext, AES-256 certainly has a higher security margin than AES-128. Trevor -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto