[tahoe-dev] [tahoe-lafs] #1164: use XSalsa20+AES-128 encryption

[Samuel Neves]

>From eBACS [1], AES-256 is roughly 60% slower than AES-128. XSalsa20 is
around 25% to 50% faster than AES-128. So it does seem to make a dent on
performance.

[1] http://bench.cr.yp.to/results-stream.html (search for "arm")

On 03-09-2010 19:56, Jack Lloyd wrote:
> On Fri, Sep 03, 2010 at 06:13:20PM -0000, tahoe-lafs wrote:
>> Comment (by zooko):
>>
>>  Upon Samuel Neves's questioning, I added some notes about AES-128 vs.
>>  AES-256 for this:
>>
>>  http://tahoe-lafs.org/trac/pycryptopp/ticket/46#comment:2
>>
>>  I would be interested in the feedback of Jack, Yu Xue, David-Sarah, or
>>  Brian about this issue.
> I couldn't really comment on the performance aspect, though obviously
> AES-256 will be slower anywhere due to the extra rounds.
>
> Using AES alone, my preference is definitely for AES-256, because
> while AES-256 has known related key attacks, AES-128 has probable
> related key attacks (IIRC 9 of 10 rounds are breakable using related
> key attacks already, and the AES key schedule is overall pretty weak
> regardless of the key length; I expect relatively practical related
> key attacks on the full AES-128 and AES-192 will be found within a
> year or three at most), so IMO if you're using AES anywhere where
> there is any possibility of related keys you're already in trouble.
>
> So (assuming related key attacks are probably feasible against all the
> AES variants even if we don't know how to break the full versions just
> yet for 128 and 192 bit key schedules), the only real differentiator
> between the AESs is the key length (and the difference between 128 and
> 256 bit keys only matters if an attacker has a quantum computer many
> orders of magnitude bigger than any yet constructed) and the number of
> rounds. I don't really have that much confidence in 10 rounds of AES
> (I also don't like kimchi), thus my aforementioned preference for
> AES-256.
>
> However I definitely think that AES-128+XSalsa20 is safer than AES-256
> on its own.  Given the performance constraints in this particular
> situation, I'm not sure that it makes that much sense to use AES-256,
> but I suppose that will depend on what kind of numbers we actually end
> up seeing on ARM. If it turns out AES-256+XSalsa20 is actually only,
> say, 10% slower than AES-128+XSalsa20, and a modern ARM still seems
> capable of handling a large amount of traffic before it becomes CPU
> bound, then maybe using AES-256 would be reasonable purely on the
> basis of being conservative. If it's 50% slower, and the ARM can't
> keep up, then that argues pretty strongly for 128.
>
> I also couldn't reasonably comment on the perceptual issues re 256 vs
> 128; my take is the only sane reason to use AES of any keysize for
> anything is compatability with other systems.
>
> tl;dr: We know AES-256 will always be slower than AES-128. We should
> measure how much slower it will be on the platform we have identified
> as being important for good performance; if AES-256 turns out to be
> not much of a hit, we should use it just to be conservative [1], but
> if it hurts performance too much, AES-128 seems like it would be fine.
>
> -Jack
>
> [1] And to ensure Tahoe can be used to store TS/SCI information! I've
> got buckets of the stuff sitting around here but I would hate to put
> it into a system that has crypto only approved up to secret. :)
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>