Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[STDS-802-11-TGBC] To SHA or Keccak?



This is the follow on to my participation in today's session.  I cannot join on Thursday as that is Yom Kippur.

==============================

The Keccak functions:  SHAKE, cSHAKE, and KMAC add to the implementation code base.  Is there value in this additional code cost?

Per RFC 8032, if you are using EdDSA448, you WILL need SHAKE256. EdDSA128 uses SHA-512.  There is every indication that when FIPS 185-6 final is released (already 9 months late) this will remain. It is unlikely that NIST will insist on SHAKE128 for EdDSA128 and break backwards compatibility at this time.

(even though I and others submitted a negative comment on the draft on this point)

But I do not see EdDSA448 in 802.11bc, so this does not "force your hand".

Many performance reports show SHA-256 and SHAKE128 to be similar in speed.

Thus hash performance is a plus for avoiding more code.

SHAKE DOES give a standard for variable output.  See table 4 in FIPS 202 Appendix A.1.  This avoids potential specification flaws in how to vary output length when using SHA-256.

Thus variable output length is a plus for Keccak.

cSHAKE and KMAC provide a standard method for including a "domain string".  There is general inconsistency and debate on how to do this best with SHA-2.

Thus consistent method for "domain string" inclusion is a plus for Keccak.

Note USE cSHAKE rather than just SHAKE for this reason.

Keyed-Hashing for Message Authentication is twice as efficient with Keccak than SHA-256.  A single KMAC sponge operation is equivalent to HMAC (RFC 2104) which uses 2 SHA calls.

Thus keyed MACing is a BIG plus for Keccak.

But how often does 802.11bc perform a keyed MAC?  Once per session setup?  Or per message?  Maybe not important on clients but what about high-demand servers?

Key derivation functions from a Diffie-Hellman key exchange takes a single KMAC operation compared to HKDF (RFC 5869) which needs at least 4 SHA calls.  But I do not see DH in 802.11bc, so this may not be a consideration.

=========================

We had to move from SHA-1 to SHA-2 for security concerns.  So far this is not true for SHA-2 to Keccak, and NIST so far is comfortable with SHA-2 against published attacks.  Security is NOT a reason, at least now and maybe even PQC, to recommend Keccak over SHA-2.

My recommendation to the taskgroup is to review the distinctions I point out above and make your decision on a reasonable comparison of SHA-2 and Keccak.

If you DO decide to use Keccak, I will assist in cleaning up the text had getting the function calls right.

Feel free to contact me for further clarifications.

Now all this changes if you are concerned of small sensor implementation and are following NIST's Lightweight Crypto Competition (https://csrc.nist.gov/projects/lightweight-cryptography).

Go Xoodyak!  :)

________________________________________________________________________
To unsubscribe from the STDS-802-11-TGBC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBC&A=1