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