How to get my krb5 crypto lib upstream?

[Jeffrey E Altman]

On 5/31/2023 4:08 PM, David Howells wrote:
> Fair point.  In rxgk, I use key_len, key_bytes, block_len, cksum_len plus the
> name for procfs purposes.  I also wonder if I need separate key_len and
> key_bytes if I'm not supporting DES (DES keys gets expanded IIRC).  Also, some
> of the checks I'm doing could perhaps be moved into the krb5 lib.

The "K" in RXGK is RFC3961 without support for weak ciphers.  No DES, no 
3DES
and no RC4-HMAC.   DES keys are never expanded.

The supported ciphers are

  * aes128-cts-hmac-sha1-96 (RFC3962)
  * aes256-cts-hmac-sha1-96 (RFC3962)
  * aes128-cts-hmac-sha256-128  (RFC8009)
  * aes256-cts-hmac-sha384-192  (RFC8009)

There are other Kerberos ciphers that could be used with RXGK but there 
are no RXGK server implementations that use them.   None of the RFC3961 
ciphers or the RFC3961 interfaces support AEAD modes.

Luke Howard proposed "AEAD Encryption Types for Kerberos 5" 
https://datatracker.ietf.org/doc/draft-howard-krb-aead/ to IETF Kitten 
which would add AES128 and AES256 GCM, CCM, and OCB modes. However, 
there is some resistance to these additions because at the moment all 
RFC3961 ciphers are safe for use with long term keys and repeating 
cipher state; AEAD modes are not.

RXGK can be constrained such that it is safe for use with AEAD modes and 
I would like to see Luke's draft be adopted if only because CTS-HMAC is 
not supported by Intel QAT and GCM is. Adoption of Luke's draft would 
not only benefit AuriStorFS but NFSv4 gss-krb5 as well.

My suggestion is that the kernel should provide an RFC3961 API for use 
by gss_krb5 applications.   AEAD modes can be added to that if and when 
Luke's draft is adopted.

Jeffrey Altman



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4039 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-afs/attachments/20230531/f2fd37d0/attachment.p7s>