Subject: [Uta] AES-128 vs. AES-256

From: joe <[email-masked]>
Date: Tue, 18 Nov 2014 17:49:49 -0500 (EST)

Hi,

On Tue, 18 Nov 2014, Viktor Dukhovni commented on some feedback
from me that Stephen Farrell had kindly passed along:

> > 4.2.1 states that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 SHOULD
> >    be the first cipher proposed, and servers SHOULD prefer that
> >    cipher whenever is proposed.
> > 
> >    I'd prefer to see the AES_256 version recommended instead, given
> >    that it provides a large margin of cryptographic strength.
> 
> The cryptographic margin in AES-128 is I believe quite sufficient
> for best current practice.  The performance benefits can lead to
> greater adoption.  Don't let the perfect be the enemy of the good.

To be explicit, my preference for AES-256 over AES-128 is a function of
three factors:

1) The NSA requires AES-256 in Suite B for TOP SECRET content. That 
implies to me that at least under some circumstances, some smart 
folks think that AES-128, even though good, just isn't good *enough*

That may reflect the fact that TOP SECRET content may need to stay 
protected for fifty years (and that's a long time), or it may be 
related to something else (like worries about quantum computing), but at 
least for some content, we know that AES-128 isn't believed to be good 
enough. See https://www.nsa.gov/IA/Programs/suiteb_cryptography/
[I'm not cleared and I'm not doing anything classified, but why not
think like an civil engineer and build in a margin of safety, eh?]

2) There's some indication that the reason why the NSA mandates AES-256
actually *is* concern around the risk of quantum crypto, see for example
https://twitter.com/SteveBellovin/status/311545287313330176

Given a $10.8 billion dollar budget for the Consolidated Cryptology 
Program (see for example www.wired.com/2013/08/black-budget/ ), I'd
expect a bit of progress, and heck, who knows, they may have made
better progress than is generally known. If that's the case, AES-256 
would be a better option than AES-128, for the reasons discussed at  
http://en.wikipedia.org/wiki/Key_size#Effect_of_quantum_computing_attacks_on_key_strength

3) The performance penalty I'm seeing isn't big enough to be a show 
stopper for most use cases. Testing with openssl speed aes-128-cbc (etc)
on even a basic laptop, I'm seeing:

type             16 bytes     64 bytes    256 bytes   1024 bytes  8192 bytes
aes-128 cbc     111191.87k   121014.21k  123128.49k   123900.23k  123483.48k
aes-256 cbc      82304.19k    87485.03k   89003.26k   89442.30k    89513.98k

If that performance hit is a big deal for a particular situations, by all
means fall back to AES-128, but in cases where there's still plenty of 
computational "pedal" left under your foot, why not push harder and use 
it?

Naturally, if AES-256 were to actually have *issues* that AES-128 
*doesn't* (and I'd note that periodically I've seen things like
https://www.schneier.com/blog/archives/2009/07/another_new_aes.html ),
well, that would be a different matter. Is *that* the concern that folks
have with prioritizing AES-256 over AES-128?

Regards,

Joe St Sauver ([email-masked] or [email-masked])
Farsight Security

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 19 Nov 2014 00:13:32 +0100

Hi Joe,

Sorry, not for not replying in-line to your lenghty text, just
wanted to throw this out there:

In a project I participate (bettercrypto.org) we had lenghty
discussion for about a year on this topic. In the end we decided on
reducing our recommendations to AES128. Basically for the following
reasons:

  .) There are more attacks known on (reduced round!) AES256
  .) Vincent Rijmen told us to use AES128
  .) Performance

:)

Aaron

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Nov 2014 11:14:18 -0500

Joe,
> think like an civil engineer and build in a margin of safety, eh?]
I to have been told that reason we have AES-256 is as a precaution in case
quantum computers can be built with enough Qbits to attack symmetric 
ciphers like AES.
if that scenario pans out, then a 256-bit key becomes as strong as a 
128-it key
(in the absence of such machines). The margin of safety you suggest 
impose a
performance hit, so it's not obvious that we ought to mandate AES-256 here,
especially for software implementations. In my experience folks will 
jump to the
"bigger is better" option too quickly, and the performance hit might 
then cause them
to reject using encryption at all, which is not the desired outcome, right?

Steve

---

From: joe <[email-masked]>
Date: Wed, 19 Nov 2014 11:59:50 -0500 (EST)

Hi Stephen,

> The margin of safety you suggest impose a
> especially for software implementations. In my experience folks will jump to
> the "bigger is better" option too quickly, and the performance hit might 
> then cause them to reject using encryption at all, which is not the 
> desired outcome, right?

The "bigger is better" thing is probably cultural, you know? (Cadillac 
cars are inherently more meritorious somehow than SmartCars, well, at
least if you're 6'4" and need room for a big dog and a cowboy hat, too 
:-)). Of course, that "superiority" only lasts until it's time to parallel
park. :-)

But to get to your point on the performance "hit", when I benchmarked
AES-128 vs. AES-256 in OpenSSL with the openssl speed command, I just 
didn't see a huge level of pain:

The 'numbers' are in 1000s of bytes per second processed.

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc     110889.82k   120032.96k   123677.01k   125399.38k   125501.99k
aes-256 cbc      81992.44k    87824.68k    88246.53k    88979.11k    89647.79k

And if performance IS the lynch pin criteria for excluding AES-256, I'd 
note that Camellia-256 offers performance that's neck and neck with 
AES-128 at least for larger block sizes:

camellia-128 cbc 87456.49k   132199.41k   149190.74k   154601.47k   154501.12k
camellia-256 cbc 75502.15k   102390.12k   113707.92k   116351.32k   117317.06k

I'd also note that for a long time people did RC4 because of its superior 
performance, e.g., on the same system:

rc4             318199.20k   323420.07k   334649.17k   342183.94k   344094.14k

Now, obviously, however, RC4 has been widely deprecated, and for good 
reason. So why mention it?

>From my POV there was and is a BIG difference between RC4 and ANY version 
of AES or ANY version of Camellia. And yet, folks successfully moved away 
fromv RC4 with no apparent performance-driven abandonement of TLS as a 
result!

Bottom line, I'm just not seeing the "we can't handle AES-256 because of 
its inferior performance relative to AES-128" argument, at least not based 
on the comparative metrics shown above (stipulated: that's for one crypto 
library (openssl), on one particular operating system, on one particular
piece of hardware). 

If there are dramatic issues on other configurations where it would be a 
"dealbreaker," I'd love sample metrics to be able to better understand 
that performance concern.

Thanks,

Joe

---

From: Benjamin Black <[email-masked]>
Date: Wed, 19 Nov 2014 09:21:11 -0800

> that performance concern.

100% agree. As I've argued (vigorously) on a related list, I've seen zero
evidence of informed performance concerns, as opposed to prevalent
uninformed FUD, stopping TLS deployment. Companies deploy TLS for business
reasons. Relatively minor performance variations don't trump solid business
reasons. That said, reducing the overhead is desirable, especially for
mobile clients, and at large scale that ~25% difference can matter. There
are good reasons to choose 128-bit ciphers, but almost nobody is qualified
to make the decision, hence blanket recommendations in BCP documents.

b

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Nov 2014 14:20:37 -0500

Joe,

> :-)). Of course, that "superiority" only lasts until it's time to parallel
maybe that's why some big, fancy cars have automatic parallel parking 
options ;-).
> aes-256 cbc      81992.44k    87824.68k    88246.53k    88979.11k    89647.79k
These numbers suggest a 35%-40% performance penalty for 256-bit vs. 
128-bit AES.
So, on a percentage basis, that's non-trivial. But, in terms or raw 
performance,
it may not be an issue for many platforms. Not clear how this plays out
for smart phones. I hope someone has those numbers, and an indication of the
possible power (battery) costs for that context.
> AES-128 at least for larger block sizes:
I don't think we should focus on other algs, for now, although I understand
your point.

I didn't say "we can't handle" 256-bit AES. I suggested that it's not clear
that we need to mandate its use, or even make it the 1ts choice in a 
negotiation,
and that it might impose a performance burden that would be 
counterproductive,
relative to the goals of this WG.

Steve

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 19 Nov 2014 20:34:20 +0100

* Stephen Kent <[email-masked]> [141119 20:20]:
> These numbers suggest a 35%-40% performance penalty for 256-bit vs. 128-bit
> AES.

I'm far from an expert on GCM, but as far as I know from feedback
from Google engineers there are problems with GCM on mobile devices,
which is why they (and others) are pushing to standardize
ChaCha/Poly1305 in TLS. If a more qualified person can comment and
clarify on that matter I think that'd be useful for the discussion.

> relative to the goals of this WG.

I agree.

As to the whole "quantum threat" point made earlier: This has been
blown out of proportion by the media. We're far away from a usable
quantum computing architecture and even more so for one that might
pose a threat to cryptographic primitives. Then again Post Quantum
algorithms are the best direction we should be looking into not
building upon existing algorithms. AES128 should suffice for the
timeframe of this WG and the current documents that we should -
really - get out of the door soon.

Just my 3 Cents,
Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 19 Nov 2014 20:40:19 +0100

* Aaron Zauner <[email-masked]> [141119 20:34]:
> [...]

Also; isn't this an issue CFRG is tasked to handle instead of WGs
themselves? We might ask for advice if we cannot find consensus.

Aaron

---

From: Brian Smith <[email-masked]>
Date: Wed, 19 Nov 2014 12:14:16 -0800

> possible power (battery) costs for that context.

See https://jve.linuxwall.info/ressources/taf/aesmeasurements.txt for
some numbers (the ARM section at the bottom).

I want to clarify that I don't think people who choose AES-256 over
AES-128 are wrong to do so. In the past, I've argued for listing
AES-128 cipher suites ahead of AES-256 in web browsers' ClientHello
messages. My arguments were based on tradeoffs primarily concerning
web browsers on smartphones given the state of things in 2013. The
less well that describes your application, the less relevant my
arguments are. In general, I think that if your application isn't hurt
by using AES-256 over AES-128, and particularly if you have a
timing-attack-resistant implementation, then I think it makes sense to
choose AES-256 over AES-128.

It would be nice of the BCP didn't say or imply that AES-128 should be
chosen over AES-256. But, I think the discussion could go around and
around in circles. Perhaps the most practical thing to do is publish
the BCP now, and then work on an updated BCP improves the cipher suite
issues, particularly when ChaCha20-Poly1305 cipher suites can be
considered, and when the impact of the publication of this version of
the BCP can be measured (particularly with respect to the TLS_DHE_*
cipher suites).

Cheers,
Brian

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 19 Nov 2014 14:37:50 -0700

> really - get out of the door soon.

Hear, hear!

And: this BCP is a snapshot. It can be updated or obsoleted by other 
RFCs at any time - even next year if we please. IMHO 128-bit AES is good 
enough for *this* document and we will update the recommendations as 
needed through the usual processes.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Nov 2014 22:33:06 +0000

On 19/11/14 19:40, Aaron Zauner wrote:
>> AES128 should suffice for the
>>> timeframe of this WG and the current documents that we should
>>> - really - get out of the door soon.

+many^many and I also agree with Steve K's opinions here.

> themselves? We might ask for advice if we cannot find consensus.

I don't think we ought ask CFRG this question. There's enough
folks here who know enough that that's not needed.

Wrt post-quantum stuff, that would be a good topic for CFRG and
I know there's some interest there too. But there's no need to
formally "ask" them about it - just subscribe and send mail to
their list. (Not everything has to be formal:-)

S.

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 19 Nov 2014 23:37:39 +0100

> their list. (Not everything has to be formal:-)

Yup, I meant the post-quantum stuff w.r.t. asking CFRG. I'm
subscribed there, and some people working on exactly that topic
are as well. But to be honest I don't see a pressing reason to
do so right now.

Aaron

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 19 Nov 2014 22:44:19 +0000

On 19/11/14 22:37, Aaron Zauner wrote:
> I don't see a pressing reason to do so right now.

That's also fair. (And I'd prefer to get an answer about
curves from 'em first anyway;-)

S

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 19 Nov 2014 23:48:50 +0100

* Stephen Farrell <[email-masked]> [141119 23:44]:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 

Yes. That's also what I've been looking forward to get (and
incorporate into other projects I'm involved with). So let's not
bother them too much.

Aaron

---

From: Leif Johansson <[email-masked]>
Date: Thu, 20 Nov 2014 09:15:31 +0100

On 2014-11-19 23:33, Stephen Farrell wrote:
>>>> timeframe of this WG and the current documents that we
>>>> should - really - get out of the door soon.
> 

That includes me both as chair and as an individual.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 20 Nov 2014 09:17:43 +0100

Folks - this thread is really interesting but I (with chair hat on)
don't see anything that looks like consensus for changing the current
text, nor do I see anything that looks like a concrete proposal.

In the absence of consensus the current text stays.

The WGLC ends tomorrow.

	Cheers Leif

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 20 Nov 2014 08:45:10 +0000

> are as well. But to be honest I don't see a pressing reason to

You'll likely get a simple answer.  The quantum attack on block
ciphers, were it to become practical, is IIRC a generic O(N)->O(sqrt(N))
search speedup.  This is very much unlike the situation with RSA
or ECDH where the Shor attack is far more devastating.

There are IIRC no published quantum speedups against block ciphers
except for the generic one.

So while we may yet need new post-quantum asymmetric algorithms,
there is no dramatic need for new symmetric ones, just double the
keysize.  As for NSA, they originally specified AES-192 for TOP
SECRET, but this never became popular in hardware (Intel AES-NI,
...) so the suite-B spec got changed to AES-256.

The whole thing boils down to how many years one's data must remain
secret, and how concerned one is about imminent scalable QC hardware.

I don't know whether the CFRG can answer either question, but I'd
guess that Scott Aaronson is not yet saving up to buy his first QC
PC on Amazon.

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 20 Nov 2014 12:15:14 +0100

Hi Viktor,

> except for the generic one.

Thanks for your insight. Yes I'm aware that Grover's algorithm is the
best speedup for symmetric crypto. That was more of a general question
on pqcrypto algorithm guidance, but as far as I know none of them are
suitable for use in TLS /right now/. But I'm also not an expert on that
subject.

> guess that Scott Aaronson is not yet saving up to buy his first QC

Heh. :)

Aaron