I would actually like to make a presentation at SAAG about KMAC as a KDF
and why the IETF should incorporate it.
SP 800-185 was published back in Dec 2016. This clearly shows how to
use KMAC as a replacement for HMAC. Many in the security community
'rejected' SHA3 as only marginally faster than SHA256. They missed that
thus KMAC is 2x as fast as HMAC-SHA256!
SP 800-56Cr1 was published in Apr 2018. Here it was NOT as clear that
KMAC as a KDF was a clean replacement for HKDF when the source was an
ECDH derive secret. SP 800-108 has not been updated since 1st published
in Oct 2009. So there was a reasonable question as to KMAC being equal
to HKDF for an ECDH derived secret.
But, "anyone skilled in the arts" of understanding crypto algorithms
(not necessarily at the level to create them) could see from FIPS 202
(Aug 2015) that the sponge function in the form of SHAKE directly
performs both processes in HKDF - Extract and Expand. But it took until
800-185 for the "approved" method to add keying material into SHAKE.
Thus KMAC as defined in 800-56Cr1 is cryptographically equivalent to
HKDF and MANY fewer hash operations.
So the standard has been around for some years. The cryptoanalysis is
that of the sponge function being a PRF; there is no practical limit on
how much you can squeeze out of the sponge. Well there is a limit of
2^(n-1) bits, I believe. It has been us crypto-plumbers that have not
been paying attention.
On 1/24/20 7:45 AM, Daniel Migault wrote:
Hi,
Thanks Robert for the update. I would like to get feed backs from the
tmrid and especially hip WG of their thoughts regarding this new proposal.
Bob, could you updates the WGs on the maturity level of your proposal
as well as the next (technical) steps to complete that work.
Yours,
Daniel
On Thu, Jan 23, 2020 at 10:47 AM Robert Moskowitz
<[email protected] <mailto:[email protected]>> wrote:
I have added sec 8.2, discussing the security of using KMAC as a
KDF. This is based on a conversation I had with the Keccak team
at the IACR conference at Columbia U earlier this month.
Basically the KMAC output is a PRF and as such can be directly
divided into multiple keys. No need for a compress and expand
process on the output of ECDH; this is done implicitly in the sponge.
-------- Forwarded Message --------
Subject: New Version Notification for
draft-moskowitz-hip-new-crypto-04.txt
Date: Thu, 23 Jan 2020 07:43:48 -0800
From: [email protected] <mailto:[email protected]>
To: Stuart Card <[email protected]>
<mailto:[email protected]>, Adam Wiethuechter
<[email protected]>
<mailto:[email protected]>, Robert Moskowitz
<[email protected]> <mailto:[email protected]>,
Stuart W. Card <[email protected]>
<mailto:[email protected]>
A new version of I-D, draft-moskowitz-hip-new-crypto-04.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.
Name: draft-moskowitz-hip-new-crypto
Revision: 04
Title: New Cryptographic Algorithms for HIP
Document date: 2020-01-23
Group: Individual Submission
Pages: 12
URL:
https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-04.txt
Status:
https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/
Htmlized:
https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-04
Htmlized:
https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto
Diff:
https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-04
Abstract:
This document provides new cryptographic algorithms to be used with
HIP. The Edwards Elliptic Curve and the Keccak sponge functions are
the main focus. The HIP parameters and processing instructions
impacted by these algorithms are defined.
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at
tools.ietf.org <http://tools.ietf.org>.
The IETF Secretariat
--
Tm-rid mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/tm-rid
--
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email protected]
There's no limit to what can be accomplished if it doesn't matter who
gets the credit
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
