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

[Jack Lloyd]

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. :)