[Ach] The sad story of lonely AES-CTR

ianG iang at iang.org
Fri Dec 20 14:43:06 CET 2013


On 18/12/13 17:34 PM, Aaron Zauner wrote:
>
> On 18 Dec 2013, at 15:23, <robin.balean at a-trust.at> <robin.balean at a-trust.at> wrote:
>
>> This is an interesting paper and actually they give the answer to your question on page 5.  In fact GCM is just CTR mode with Galois Hash for authentication.
> I’m aware of that. A quick peek on wikipedia will tell you that as well :)
>
>>   It doesn't say why AES-CTR with other MAC algorithms are not supported.
> I guess I’ll have to ask someone involved with the TLS WG. It’s not that they are not possible. They are simply not supported in the TLS standard (you can use them in other protcols, like SSH per default for example). HPN-SSH uses aes-ctr + window scaling and a couple of other tricks to achieve extremely good performance for data transfers. If you are a FreeBSD user: they switched to HPN-SSH a while ago. A lot of HPC sites run HPN-SSH on linux as well.
>
>> Nevertheless they do state on page 30:
>> "AES-GCM is the best performing Authenticated Encryption combination among the NIST standard options (esp. compared to using HMAC SHA-1)”
>
> What they mean is not AES-CTR-SHA1 but AES-SHA1 - if I understand that correctly (which I suppose means some other, non parallelizable block cipher mode, right?).
> They state AES-CTR explicitly every time.
>
> The big thing about (galois) counter mode is that it’s parallelizable. Which most other block cipher modes are not. Still I don’t see why there is no AES-CTR option in TLS ciphersuites.
>
> @ian, Do you know anything about that?


I don't want to :)

There are several things going on here.

1.  there has been a big 'thought' shift in the last decade.  We have 
realised that modes and macs and padding are bad, and we need AE 
algorithms (because software side is too hard to get right reliably). 
So things like GCM are thrust forward, but this game has only just 
begun.  In particular CAESAR is a competition to find a better AE, so we 
are basically in waiting...

2.  There are so many modes and suites and thems and thats that the TLS 
WG and similar are always arguing about what to do.  There is no 
particular belief that what is good for users will win those battles. 
The problem here is that because there are so many suites, and because 
there is such a battle to get a new suite in place and broadspread use, 
the suites we have are all last decade's thinking ... so the arguments 
roll on.

3.  Snowden has put the cat amongst the pigeons, everyone is rushing to 
put in PFS modes, and deprecate all the old stuff.  If one is an 
archivist of ciphersuites, this is a busy time!  Oh, and we need 
opportunistic modes.  Oh, and we need ...

4.  there is also some patent FUD in there somewhere.

5.  There is a big fight between the software people and the hardware 
people.  They have very big differences which spill out to modes. 
Software people want logical simplicity, agility, and don't care about 
parallelizable because it is all done serially anyway.  Hardware people 
want circuit simplicity but not too much because they're out of a job, 
and want masses of parallelization, but care less about ultimate 
security than market adoption for hardware.  So they hate agility.

6.  CTR versus anything else has its fans and critics.  CBC too, and 
both sides argue for a long time.  To my mind, it somewhat depends on 
context, but really, we need AE....

7.  SO, if we switch to stream ciphers like chacha and 
near-AE-algorithms like poly1305chacha20 then we don't care about a lot 
of the above.  So the smart money atm is putting poly1305chacha20 into 
TLS and SSH.

8.  then there is MD5 which is being replaced in all suites ... but does 
this mean the suite is being changed or dropped?  Then there is SHA1 
which should also be replaced, ditto...  And des and t-des and so forth, 
each "suggestion" causes an issue.



Ok, that's some things going on in the space.  What it really amounts to 
is that there is often not one logical reason, but a roomful of 
interests.  You might not get an answer.

iang

> Aaron
>




More information about the Ach mailing list