[39623] in Kerberos
Re: why is aes sha1 the default encryption type
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Jun 23 16:14:00 2026
Message-ID: <c1dc71d8-23c4-437a-a1e0-89bdf7cad1b1@mit.edu>
Date: Tue, 23 Jun 2026 16:12:38 -0400
MIME-Version: 1.0
To: Charles Hedrick <hedrick@rutgers.edu>,
"Kerberos@mit.edu"
<Kerberos@mit.edu>
Content-Language: en-US
From: "Greg Hudson" <ghudson@mit.edu>
In-Reply-To: <PH0PR14MB54932589DD184BAE4A07A48BAAEE2@PH0PR14MB5493.namprd14.prod.outlook.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: kerberos-bounces@mit.edu
On 6/23/26 08:43, Charles Hedrick via Kerberos wrote:
> When there's a perfectly good aes sha2 type?
1. It is highly interoperable. Every Kerberos implementation of
significance implements aes-sha1, going back many years. Microsoft
either hasn't implemented aes-sha2 or only implemented it in 2025 (I
can't easily tell which), so the clock has at best barely started on
that kind of reach for aes-sha2.
2. The known flaws in SHA-1 do not affect its use as a MAC.
3. Kerberos enctype negotation isn't perfect. It works well enough for
client interoperability, but when provisioning keytabs for servers you
have to select an enctype that the server software supports. There is
also this edge case if it hasn't been fixed on the Microsoft side:
https://krbdev.mit.edu/rt/Ticket/Display.html?id=9089
I get that using SHA-1 in any capacity can run afoul of regulatory
systems, which aren't always nuanced enough to recognize that it is
still believed to be secure as a MAC. But changing the default doesn't
necessarily help with compliance; as long as the system can negotiate
down to aes-sha1 then it still has SHA-1 in its attack surface.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
