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

Reply via email to