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

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
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>

On Thu, Oct 3, 2019 at 12:06 PM Robert Moskowitz <rgm-sec@htt-consult.com>
wrote:

> 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:
>
> 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 <rgm-sec@htt-consult.com>
> 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.
>>
>> 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
>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>
>