[Ach] The sad story of lonely AES-CTR

Aaron Zauner azet at azet.org
Wed Dec 18 11:56:04 CET 2013

On 18 Dec 2013, at 10:01, <robin.balean at a-trust.at> <robin.balean at a-trust.at> wrote:

>   However AES-GCM is better than both of these because it has built in authentication which eliminates problems that can occur when an implementation performs the MAC and Encrypt operations in the wrong order.
I doubt that it’s more secure by default. They are arguing currently on the TLS WG heavily about mac-then-encrypt, mac-pad-encrypt and encrypt-then-mac. I prefer e-t-m. Thats also what I specified with UMAC in the SSH configuration. As for other MACs: It heavily depends on standards and implementations and also the MAC in use.

>  I expect it is also quicker than MACing separately.
That was the reason I acutually started the thread. I do not think that GCM is faster than CTR. Since some steps have to be performed twice or even three times in a row. Needless to say there are not good software implementations and instruction pipelines available that optimize GCM (for Intel processors!). Good overview: http://en.wikipedia.org/wiki/Galois/Counter_Mode#Performance

If I have time for that I’ll write a performance benchmark for both GCM and CTR + MAC on Intel and non-Intel CPUs. I guess there are some out there already since DJB benchmarks a lot of algorithms. I’ll look it up in the afternoon.

> Still, your question is valid.  CTR mode was one of the advertised advantages of AES when it first came out.   AES has loads of other modes too, some also offering authenticated encryption but quite a few are patented (e.g. OCB).  Perhaps CTR is not that popular since unpatented authentication modes such as GCM came out.  
I’m not sure. It seems the draft was never accepted into the standard.

> You still have to be careful with GCM by the way: http://eprint.iacr.org/2013/157.pdf
Thanks for the reference!


> Robin
> -----Ursprüngliche Nachricht-----
> Von: Aaron Zauner [mailto:azet at azet.org] 
> Gesendet: Mittwoch, 18. Dezember 2013 09:21
> An: Robin Balean
> Cc: ach at lists.cert.at List Mailing
> Betreff: Re: [Ach] The sad story of lonely AES-CTR
> Well. AES-CBC isn’t either. You’ll have to use some HMAC for that in the cipher suite of course.
> AES-CTR does not have (to the best of my knowledge) vulnerabilities currently known and you can parallelize it very well in hardware and software (you can’t do that with chaining modes like CBC).
> Aaron
> On 18 Dec 2013, at 09:15, robin.balean at a-trust.at wrote:
>> The reason is probably because AES-CTR is not an authenticated encryption mode.  It just provides encryption.
>> Robin
>> -----Ursprüngliche Nachricht-----
>> Von: ach-bounces at lists.cert.at [mailto:ach-bounces at lists.cert.at] Im Auftrag von Aaron Zauner
>> Gesendet: Dienstag, 17. Dezember 2013 20:26
>> An: ach at lists.cert.at List Mailing
>> Betreff: [Ach] The sad story of lonely AES-CTR
>> Ohai.
>> Does anyone know why OpenSSL 1.0.1e supports AES-CTR as block cipher mode but misses AES-CTR completely in ciphersuites?
>> As it seems Counter Mode never made it to the RFC: http://tools.ietf.org/html/rfc5288
>> GCM did.
>> “If my calculations are correct” AES-CTR would be significantly faster than AES-GCM (since openssl speed does not support benching aes-gcm nor aes-ctr I simply went for a complexity comparison - I should maybe write a real test for that as well).
>> BTW. Ben Laurie commited an exotic chaining mode called IGE to OpenSSL some time ago:
>> “”"
>> Infinite Garble Extension (IGE) is a block cipher mode[1]. It has the property that errors are propagated forward indefinitely. Bi-directional IGE (biIGE) propogates errors in both directions: that is, any change to the ciphertext will cause all of the plaintext to be corrupted. 
>> “”"
>> http://www.links.org/files/openssl-ige.pdf
>> Aaron

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1091 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20131218/2581e493/attachment.sig>

More information about the Ach mailing list