Hi Ilari, >Why wait for those? It seems to me that one could add the SHA-3 >ciphersuites already, as SHA-3 has been standardized years ago.
Good idea, I will start wring on a draft doing that just that. >Well, duplex mode is a bit special-purpose thing, for cases where one >wants to reduce number of primitives to reduce code size, or has >hardware acceleration to make it much faster than AES-GCM. That is also a good idea. NIST stated a long time ago that they would standardize an AEAD based on Keccak, but that has not happened so far. I was thinking that Keccak duplex mode could be used in the key schedule. It feels high level like a more natural construct for a key schedule. You cen see it as a generalization of the running hash interface. Running hash: init(), update(Mi), digest = finalize() Duplex: init(), digest = update(Mi, length) But it might too much changes and too little gain to do. Cheers, John From: TLS <tls-boun...@ietf.org> on behalf of Ilari Liusvaara <ilariliusva...@welho.com> Date: Friday, 27 January 2023 at 19:15 To: tls@ietf.org <tls@ietf.org> Subject: Re: [TLS] about hash and post-quantum ciphers On Fri, Jan 27, 2023 at 11:24:59AM +0000, John Mattsson wrote: > Hi, > > I don't think non-standardized algorithms should be adopted by the > WG. Even for just assigning a number, a good first step would be CFRG. Well, getting adopted by the WG isn't a requirement for those to wind up with a number... There is expert review process as well. I think it might be time for experimental PQC codepoints for final round of testing before the final PQC algorithms. Recommended=N of course. > But this mail got me thinking: > > - NIST is expected to exclusively use SHA3 in the lattice-based PQC > algorithms. I think it would make very much sense to include SHA3 > (the SHAKE variants) at the same time as the standardized NIST PQC > algorithms. Why wait for those? It seems to me that one could add the SHA-3 ciphersuites already, as SHA-3 has been standardized years ago. - TLS_AES_128_GCM_SHA3_32 - TLS_AES_256_GCM_SHA3_48 - TLS_CHACHA20_POLY1305_SHA3_32 - TLS_KECCAK_DUPLEX_SHA3_48 I think all could use 256-level SHA-3, I don't think dropping to 128-level for AES-128 is worth it. > - TLS 1.3 hardcodes use of the quite outdated HMAC and HDKF > constructions that only exists because SHA2 is fixed-length and > suffers badly from length-extension attacks. Modern hash algorithm > like SHAKE/KMAC are variable-length and does not suffer from > length-extension attacks. If SHA3 is added in the future, I think > it would make sense to use KMAC instead of HMAC and HKDF. Might also > be nice to use the duplex construction whose security can be shown > to be equivalent to the sponge construction. Well, duplex mode is a bit special-purpose thing, for cases where one wants to reduce number of primitives to reduce code size, or has hardware acceleration to make it much faster than AES-GCM. One might want to design padding in duplex mode so that each data block is 128 octets... And another trick is only supporting plaintext sizes multiple of 8 octets (TLS 1.3 record layer can pad to it anyway). And TLS 1.3 uses hash function in four ways: - Raw hash (Transcript-Hash). - Raw HMAC (verify_data). - KDF extraction (HKDF-Extract). Which actually turns out to be raw HMAC under the hood. - KDF expansion (HKDF-Expand-Label). To actually use SHA3 to full capacity, one would have to weird stuff by redefining HKDF-Extract and HKDF-Expand-Label to be something else than HKDF. One could optimize a bit by using SHAKE256 instead of KMAC256 for the last three. I think all the standard stuff would then be doable with only one Keccak-F per MAC/KDF (maximum 135 octets in, 136 out). This would save a few Keccak-F computations. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
