Encryption type to support AES CTR mode

[Zheng, Kai]

Thanks Greg for the great comment. Very helpful!

>> There have been recent proposals to use AES-GCM for GSS-API and other Kerberos-related session protocols which use ephemeral keys.  See this email thread:
It looks to me AES-GCM for GSS-API and kerberized applications would be much helpful for the much higher efficiency of the AES mode. Particularly for a very busy, large and hot server, like Apache Hadoop HDFS NameNode Server, the reduced of CPU cycles makes a lot sense.

>> I would caution that I have yet to see any benchmark results indicating a measurable speedup from using a theoretically faster cipher mode in the context of a Kerberos-related protocol.
I would borrow some data from my colleagues: 
===
For AES/CBC mode, there will be 5x – 6x speedup for encryption (because CBC encryption cannot be parallelized. ) The encryption throughput can be 400 MB/s – 500+ MB/s. For decryption, 15x – 19x speedup for decryption. The decryption throughput ranges from 1200 MB/s – 1900+ MB/s.
For AES/CTR or AES/GCM mode, AES-NI will be 15x – 19x faster for both encryption and decryption. The encryption or decryption throughput ranges from 1200 MB/s – 1900+ MB/s.
===
Sure it may vary in different environments and servers.

So it looks like supporting AES/GCM for GSS path may sound like a good idea. It has no doubt that in a large data system to support AES-NI encryption, but having to suffer from a lower encryption in the protocol path is always a headache. That's why it also looks like a valid consideration to bypass GSSAPI, SASL or Kerberos at all.

Tracking the thread you mentioned, looks like there has been some work about supporting AES/GCM already done, but based on heimdal codebase. Wonder if it's possible to rebase it on MIT Kerberos codebase and have a try.
https://github.com/heimdal/heimdal/tree/lukeh/aes-gcm

Regards,
Kai

-----Original Message-----
From: Greg Hudson [mailto:ghudson at mit.edu] 
Sent: Wednesday, March 09, 2016 12:16 AM
To: Zheng, Kai <kai.zheng at intel.com>; krbdev at mit.edu
Subject: Re: Encryption type to support AES CTR mode

On 03/07/2016 07:35 PM, Zheng, Kai wrote:
> Looks like only AES CTS mode is supported, wonder if AES CTR is possible to be supported as well with reasonable effort. The mode is desired for its high speed up, particularly with AES-NI support. Thanks.

Kerberos is built on top of encryption primitives which must provide authenticated encryption and unlimited key reuse.  (In reality, there are certain limits to key reuse for existing encryption types before the security properties start to degrade, but they are quite large.)  AES CTR mode is not an authenticated encryption mode, nor does it tolerate key reuse.

AES-GCM is a counter-based mode which is authenticated and can achieve high performance on AESNI-capable hardware.  However, GCM requires a unique nonce for each message, and fails catastrophically if a nonce is reused.  When we considered introducing a general AES-GCM encryption type in the past, the working group effectively decided that it was unsuitable due to the potential for nonce reuse.

There have been recent proposals to use AES-GCM for GSS-API and other Kerberos-related session protocols which use ephemeral keys.  See this email thread:

http://www.ietf.org/mail-archive/web/kitten/current/msg05902.html

I would caution that I have yet to see any benchmark results indicating a measurable speedup from using a theoretically faster cipher mode in the context of a Kerberos-related protocol.  There is a risk of adding a great deal of complexity to implementations for minimal or no benefit.