Subject: [Cfrg] Please review/comment on draft-moskowitz-hip-new-crypto-02

From: Robert Moskowitz <[email-masked]>
Date: Thu, 3 Oct 2019 11:46:16 -0400

This draft adds support of EdDSA, EC25519/EC448, and Keccak hashes and 
cipher (Keyak) to HIP (rfc 7401).

The interest to this group, is I believe this is the 1st? major adoption 
of Keccak (FIPS 202, sp800-185, and sp800-56Cr1) in IETF drafts.

KMAC vs HMAC is perhaps the simplest change.  It would seem that KMAC 
(sp800-185) is more efficient than HMAC and might be of advantage to 
high capacity situations.

Then there is the KDF based on sp800-56Cr1 (called KEYMAT in HIP 
lingo).  This is a significant change from RFC5869 and sp800-108. But I 
have assurances? that it meets the needed strength requirements.

Finally I am perhaps 'jumping the gun' on NIST's lightweight crypto 
competition with specifying Keyak, but for a constrained device 
developer, it means one underlying engine to support.

TBD is a separate draft to amend RFC7402 to add Keyak to HIP's use of 
ESP (and include diet-ESP).

The only 'hidden' gotcha is EdDSA25519 using SHA512 rather than a 
cSHAKE256 with 512 bits output (see KEYMAT above).  This has code-size 
implications to constrained system developers.  Otherwise it is all 
'new' crypto.

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

A new version of I-D, draft-moskowitz-hip-new-crypto-02.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name:		draft-moskowitz-hip-new-crypto
Revision:	02
Title:		New Cryptographic Algorithms for HIP
Document date:	2019-10-03
Group:		Individual Submission
Pages:		12
URL:https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-02.txt
Status:https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/
Htmlized:https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-02
Htmlized:https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto
Diff:https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-02

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

---

From: Scott Arciszewski <[email-masked]>
Date: Thu, 3 Oct 2019 11:48:17 -0400

Ed448 (RFC 8032) uses SHAKE-256.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

On Thu, Oct 3, 2019 at 11:47 AM Robert Moskowitz <[email-masked]>
wrote:

> (sp800-185) is more efficient than HMAC and might be of advantage to high
> capacity situations.
>
> Then there is the KDF based on sp800-56Cr1 (called KEYMAT in HIP lingo).
> This is a significant change from RFC5869 and sp800-108.  But I have
> assurances? that it meets the needed strength requirements.
>
> competition with specifying Keyak, but for a constrained device developer,
> it means one underlying engine to support.
>
> TBD is a separate draft to amend RFC7402 to add Keyak to HIP's use of ESP
> (and include diet-ESP).
>
> implications to constrained system developers.  Otherwise it is all 'new'
> crypto.
>
> URL:            https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/
> Htmlized:       https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-02
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-02
>
> Abstract:
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 3 Oct 2019 12:06:17 -0400

Thank you, I am aware of that.  But Ed25519 is 'enough' for constained 
devices.  And with the UAS Bluetooth4 constrained communications, a 
32byte key is bad enough to figure out how to support (see discussions 
on the tm-rid list).

And thus why does Ed25519 not also use SHAKE?  Well I won't gripe, too 
much...

Bob

On 10/3/19 11:48 AM, Scott Arciszewski wrote:
> On Thu, Oct 3, 2019 at 11:47 AM Robert Moskowitz 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     This draft adds support of EdDSA, EC25519/EC448, and Keccak hashes
>     and cipher (Keyak) to HIP (rfc 7401).
>
>     The interest to this group, is I believe this is the 1st? major
>     adoption of Keccak (FIPS 202, sp800-185, and sp800-56Cr1) in IETF
>     drafts.
>
>     KMAC vs HMAC is perhaps the simplest change.  It would seem that
>     KMAC (sp800-185) is more efficient than HMAC and might be of
>     advantage to high capacity situations.
>
>     lingo).  This is a significant change from RFC5869 and sp800-108. 
>     But I have assurances? that it meets the needed strength requirements.
>
>     Finally I am perhaps 'jumping the gun' on NIST's lightweight
>     crypto competition with specifying Keyak, but for a constrained
>     device developer, it means one underlying engine to support.
>
>     TBD is a separate draft to amend RFC7402 to add Keyak to HIP's use
>     of ESP (and include diet-ESP).
>
>     cSHAKE256 with 512 bits output (see KEYMAT above). This has
>     code-size implications to constrained system developers. 
>     Otherwise it is all 'new' crypto.
>
>     until the htmlized version and diff are available attools.ietf.org  <http://tools.ietf.org>.
>
>     The IETF Secretariat
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: John Mattsson <[email-masked]>
Date: Thu, 3 Oct 2019 16:17:50 +0000

Interesting! Specifing some AEAD based on Keccac seems to make sense.

I noted that Keyak was not chosen in the CEASAR final portfolio, do anyone know why? I cannot find any report from the
CEASAR competition…..

Are any Keccac based ciphers submitted to the NIST's lightweight crypto competition? If I remember correctly NIST was previously talking about standardizing a Keccac based AEAD, but I have not seen any info on that for a while.

Cheers,
John

From: Cfrg <[email-masked]> on behalf of Robert Moskowitz <[email-masked]>
Date: Thursday, 3 October 2019 at 17:47
To: "[email-masked]" <[email-masked]>
Subject: [Cfrg] Please review/comment on draft-moskowitz-hip-new-crypto-02

This draft adds support of EdDSA, EC25519/EC448, and Keccak hashes and cipher (Keyak) to HIP (rfc 7401).

The interest to this group, is I believe this is the 1st? major adoption of Keccak (FIPS 202, sp800-185, and sp800-56Cr1) in IETF drafts.

KMAC vs HMAC is perhaps the simplest change.  It would seem that KMAC (sp800-185) is more efficient than HMAC and might be of advantage to high capacity situations.

Then there is the KDF based on sp800-56Cr1 (called KEYMAT in HIP lingo).  This is a significant change from RFC5869 and sp800-108.  But I have assurances? that it meets the needed strength requirements.

Finally I am perhaps 'jumping the gun' on NIST's lightweight crypto competition with specifying Keyak, but for a constrained device developer, it means one underlying engine to support.

TBD is a separate draft to amend RFC7402 to add Keyak to HIP's use of ESP (and include diet-ESP).

The only 'hidden' gotcha is EdDSA25519 using SHA512 rather than a cSHAKE256 with 512 bits output (see KEYMAT above).  This has code-size implications to constrained system developers.  Otherwise it is all 'new' crypto.

IETF repository.

Revision: 02

Pages:           12

URL:            https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-02.txt<https://protect2.fireeye.com/url?k=f5f3e143-a97a3b6f-f5f3a1d8-0cc47ad93da2-a719c860baead1e6&q=1&u=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-moskowitz-hip-new-crypto-02.txt>

Status:         https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/<https://protect2.fireeye.com/url?k=fffb3b7c-a372e150-fffb7be7-0cc47ad93da2-78d83682ccfc8b3a&q=1&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-moskowitz-hip-new-crypto%2F>

Htmlized:       https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-02<https://protect2.fireeye.com/url?k=f062eb91-aceb31bd-f062ab0a-0cc47ad93da2-22cb8134989de627&q=1&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-moskowitz-hip-new-crypto-02>

Htmlized:       https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto<https://protect2.fireeye.com/url?k=5d6da924-01e47308-5d6de9bf-0cc47ad93da2-5e91e8000092fe70&q=1&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-moskowitz-hip-new-crypto>

Diff:           https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-02<https://protect2.fireeye.com/url?k=d7be9813-8b37423f-d7bed888-0cc47ad93da2-ef6e3ea349ba4e7c&q=1&u=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-moskowitz-hip-new-crypto-02>

Abstract:

The IETF Secretariat

---

From: Scott Arciszewski <[email-masked]>
Date: Thu, 3 Oct 2019 12:18:18 -0400

Because Ed25519 was designed before SHA3 was finalized (and therefore
SHAKE-256 even existed in the standards). Additionally, Ed25519 was widely
adopted on the Internet before RFC 8032 was formalized. There was no "real
world" avenue for getting everyone to switch.

See also, Things that use Ed25519:
https://ianix.com/pub/ed25519-deployment.html

Scott Arciszewski

On Thu, Oct 3, 2019 at 12:06 PM Robert Moskowitz <[email-masked]>
wrote:

> devices.  And with the UAS Bluetooth4 constrained communications, a 32byte
> key is bad enough to figure out how to support (see discussions on the
> tm-rid list).
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 3 Oct 2019 12:30:19 -0400

I think it was Ketje as the Keccak CEASAR proposal.  As I understand it, 
Koodyak is the Keccak proposal in Round 2 of the NIST competition.  
Perhaps I need to study Koodyak a bit more.

https://csrc.nist.gov/projects/lightweight-cryptography/round-2-candidates

On 10/3/19 12:17 PM, John Mattsson wrote:
> I noted that Keyak was not chosen in the CEASAR final portfolio, do 
> anyone know why? I cannot find any report from the
>
> CEASAR competition…..
>
> Are any Keccac based ciphers submitted to the NIST's lightweight 
> crypto competition? If I remember correctly NIST was previously 
> talking about standardizing a Keccac based AEAD, but I have not seen 
> any info on that for a while.
>
> Cheers,
>
> John
>
> *From: *Cfrg <[email-masked]> on behalf of Robert Moskowitz 
> <[email-masked]>
> *Date: *Thursday, 3 October 2019 at 17:47
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Cfrg] Please review/comment on 
> draft-moskowitz-hip-new-crypto-02
>
> adoption of Keccak (FIPS 202, sp800-185, and sp800-56Cr1) in IETF drafts.
>
> lingo).  This is a significant change from RFC5869 and sp800-108.  But 
> I have assurances? that it meets the needed strength requirements.
>
> URL:https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-02.txt  <https://protect2.fireeye.com/url?k=f5f3e143-a97a3b6f-f5f3a1d8-0cc47ad93da2-a719c860baead1e6&q=1&u=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-moskowitz-hip-new-crypto-02.txt>
> Status:https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/  <https://protect2.fireeye.com/url?k=fffb3b7c-a372e150-fffb7be7-0cc47ad93da2-78d83682ccfc8b3a&q=1&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-moskowitz-hip-new-crypto%2F>
> Htmlized:https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-02  <https://protect2.fireeye.com/url?k=f062eb91-aceb31bd-f062ab0a-0cc47ad93da2-22cb8134989de627&q=1&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-moskowitz-hip-new-crypto-02>
> Htmlized:https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto  <https://protect2.fireeye.com/url?k=5d6da924-01e47308-5d6de9bf-0cc47ad93da2-5e91e8000092fe70&q=1&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-moskowitz-hip-new-crypto>
> Diff:https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-02  <https://protect2.fireeye.com/url?k=d7be9813-8b37423f-d7bed888-0cc47ad93da2-ef6e3ea349ba4e7c&q=1&u=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-moskowitz-hip-new-crypto-02>
> Abstract:

---

From: Scott Arciszewski <[email-masked]>
Date: Thu, 3 Oct 2019 12:39:31 -0400

Glancing at
https://csrc.nist.gov/projects/lightweight-cryptography/round-2-candidates
(round 2 candidates), these use Keccak:

- Elephant (Keccak is one possible instantiation)
- ISAP

Other candidates based on sponges include:

- Ascon
- DryGASCON
- ORANGE
- SPIX
- SpoC
- Xoodyak (albeit inspired by Keccak, not Keccak itself)

If you were concerned about the absence of sponge-based constructions in
NIST's Lightweight Cryptography competition, I hope this puts your mind at
ease.

Scott Arciszewski

On Thu, Oct 3, 2019 at 12:18 PM John Mattsson <john.mattsson=
[email-masked]> wrote:

> I noted that Keyak was not chosen in the CEASAR final portfolio, do anyone
> know why? I cannot find any report from the
>
> CEASAR competition…..
>
>
>
> Are any Keccac based ciphers submitted to the NIST's lightweight crypto
> competition? If I remember correctly NIST was previously talking about
> standardizing a Keccac based AEAD, but I have not seen any info on that for
> a while.
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *Cfrg <[email-masked]> on behalf of Robert Moskowitz <
> [email-masked]>
> URL:            https://www.ietf.org/internet-drafts/draft-moskowitz-hip-new-crypto-02.txt <https://protect2.fireeye.com/url?k=f5f3e143-a97a3b6f-f5f3a1d8-0cc47ad93da2-a719c860baead1e6&q=1&u=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-moskowitz-hip-new-crypto-02.txt>
>
> Status:         https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/ <https://protect2.fireeye.com/url?k=fffb3b7c-a372e150-fffb7be7-0cc47ad93da2-78d83682ccfc8b3a&q=1&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-moskowitz-hip-new-crypto%2F>
>
> Htmlized:       https://tools.ietf.org/html/draft-moskowitz-hip-new-crypto-02 <https://protect2.fireeye.com/url?k=f062eb91-aceb31bd-f062ab0a-0cc47ad93da2-22cb8134989de627&q=1&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-moskowitz-hip-new-crypto-02>
>
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-moskowitz-hip-new-crypto <https://protect2.fireeye.com/url?k=5d6da924-01e47308-5d6de9bf-0cc47ad93da2-5e91e8000092fe70&q=1&u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-moskowitz-hip-new-crypto>
>
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-moskowitz-hip-new-crypto-02 <https://protect2.fireeye.com/url?k=d7be9813-8b37423f-d7bed888-0cc47ad93da2-ef6e3ea349ba4e7c&q=1&u=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-moskowitz-hip-new-crypto-02>
>
>
>
> Abstract:
>

---

From: John Mattsson <[email-masked]>
Date: Thu, 3 Oct 2019 16:41:20 +0000

Bith Ketje and Keyak were in the CEASER final round, but not chosen for the final portfolio. It is a bit disappointing that there is no report from the competition. I understand that wring reports take time, but the lack of any reasoning behind the chosen ciphers reduces the value of the competition a bit.

XOODYAK in the NIST lightweight competition used the XOODOO permutation which they say is inspired by KECCAC-p.

John

From: Robert Moskowitz <[email-masked]>
Date: Thursday, 3 October 2019 at 18:31
To: John Mattsson <[email-masked]>, IRTF CFRG <[email-masked]>
Subject: Re: [Cfrg] Please review/comment on draft-moskowitz-hip-new-crypto-02

I think it was Ketje as the Keccak CEASAR proposal.  As I understand it, Koodyak is the Keccak proposal in Round 2 of the NIST competition.  Perhaps I need to study Koodyak a bit more.

Cheers,
John

From: Cfrg <[email-masked]><mailto:[email-masked]> on behalf of Robert Moskowitz <[email-masked]><mailto:[email-masked]>
Date: Thursday, 3 October 2019 at 17:47
To: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [Cfrg] Please review/comment on draft-moskowitz-hip-new-crypto-02

IETF repository.

Revision: 02

Pages:           12

Abstract:

The IETF Secretariat

Cfrg mailing list

[email-masked]<mailto:[email-masked]>

https://www.irtf.org/mailman/listinfo/cfrg<https://protect2.fireeye.com/url?k=774ff9ca-2b9bf53b-774fb951-864685b2085c-c93dad1cd27ae9b5&q=1&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 3 Oct 2019 16:08:55 -0400

Thanks for the review of the round 2 candidates wrt Keccak.

My desire is an AEAD that can use the same hardware 
(https://keccak.team/files/KeccakVHDL-3.1.zip) as Keccak and as much as 
the same code as possible.  That is part of the reason why I selected 
Keyak until I understand more or get better guidance.

We have found a number of embedded systems that have hardware support 
for the sp800-185 family of functions.

On 10/3/19 12:39 PM, Scott Arciszewski wrote:
> If you were concerned about the absence of sponge-based constructions 
> in NIST's Lightweight Cryptography competition, I hope this puts your 
> mind at ease..
>
> Scott Arciszewski
> On Thu, Oct 3, 2019 at 12:18 PM John Mattsson 
> <john.mattsson=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I noted that Keyak was not chosen in the CEASAR final portfolio,
>     do anyone know why? I cannot find any report from the
>
>     CEASAR competition…..
>
>     talking about standardizing a Keccac based AEAD, but I have not
>     seen any info on that for a while.
>
>     Cheers,
>
>     John
>
>     *From: *Cfrg <[email-masked]
>     <mailto:[email-masked]>> on behalf of Robert Moskowitz
>     <[email-masked] <mailto:[email-masked]>>
>     *To: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>