Subject: Re: [Hipsec] [Tm-rid] Fwd: New Version Notification for draft-moskowitz-hip-new-crypto-04.txt

From: Daniel Migault <[email-masked]>
Date: Fri, 24 Jan 2020 07:45:01 -0500

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-masked]>
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-masked]
> To: Stuart Card <[email-masked]> <[email-masked]>,
> Adam Wiethuechter <[email-masked]>
> <[email-masked]>, Robert Moskowitz
> <[email-masked]> <[email-masked]>, Stuart W. Card
> <[email-masked]> <[email-masked]>
>
>
> 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.
>
> The IETF Secretariat
>
> --
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 24 Jan 2020 08:41:14 -0500

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-masked] <mailto:[email-masked]>> 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.
>
>
>
>
>     From: 	[email-masked] <mailto:[email-masked]>
>     To: 	Stuart Card <[email-masked]>
>     <mailto:[email-masked]>, Adam Wiethuechter
>     <[email-masked]>
>     <mailto:[email-masked]>, Robert Moskowitz
>     <[email-masked]> <mailto:[email-masked]>,
>     Stuart W. Card <[email-masked]>
>     <mailto:[email-masked]>
>
>
>
>
>     Status:
>     https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/
>     Htmlized:
>     https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-04
>     Htmlized:
>     Diff:
>     https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-04
>
>     Abstract:
>     until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>
>     The IETF Secretariat
>
>     -- 
>     Tm-rid mailing list
>     [email-masked] <mailto:[email-masked]>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Jan 2020 13:41:49 -0500

Robert Moskowitz <[email-masked]> wrote:
    > 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!

I guess you saying that KMAC does not require two passes of the underlying
hash when used with SHA3?  Or is it in general?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 24 Jan 2020 14:54:26 -0500

> hash when used with SHA3?  Or is it in general?

KMAC **IS** SHA3.

Or rather both are based on the same Keccak function.

First look at FIPS 202, sec 6.2, for how SHAKE is constructed compared 
to SHA3.

Then 800-185 and how cSHAKE and KMAC are functions built on SHAKE.

So in terms of computational costs KMAC and SHA3 are very close.  It is 
really a more a question of how the bit stream is fed into the sponge 
and then how bits are squeezed out of the sponge.

And that is why not needing two distinct passes.

The sponge is inherently two passes.  First the sponge absorbs your bit 
stream, then squeeze out bits as you need them.  See figure 7 in FIPS 
202 on this.

Perhaps the difference between HKDF and KMAC as a KDF is how other info 
is fed into the process.  In HKDF, there is other info in each step of 
the process.  In KMAC all bits are absorbed before any squeezing.  And 
you squeeze out all you want before using it.

See fig 1 in Sec 5 of 800-56Cr1 and compare it to the above fig 7.

Hope this helps.

Bob