Re: [Lake] Review of KMAC in draft-ietf-lake-edhoc-08

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

A complete newcomer here, most likely lacking the context.

But all that aside - doesn't KMAC require AES-128, as opposed to AES-256? Is it a concern, and if not - why not?
--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare
 

On 7/30/21, 15:50, "Lake on behalf of Robert Moskowitz" <[e-mail] on behalf of [e-mail]> wrote:

    Greetings Lakers.  ;)

     From a Great Lakes person (only one I have not swum in is Ontario and 
    let me tell you, Superior is COLD!).

    I have looked at your use of KMAC and it is a good start, but not as 
    good as can be done with KMAC.  Please see my draft:

    https://datatracker.ietf.org/doc/draft-moskowitz-hip-new-crypto/

    Not only do I use KMAC for HMAC replacement, but also as the KDF.  I 
    also include Xoodyak, one of the NIST LWC finalists of which only 4 
    include hashing.

    This draft has been implemented in openHIP and reviewed by Team Keccak.

    WRT to use as a KDF.  In my discussions with NIST and Team Keccak 
    (including F2F at IACR RWC Jan '20) KMAC directly does the 
    extract-and-expand.  You do not need to invoke KMAC twice.


    In SP800-56Cr1 sec 8.3, KMAC is not included in a 2-step KDF as it is 
    waiting SP800-108 update.  But in my research I see KMAC doing exactly 
    what it takes the two HMAC steps to accomplish.  Team Keccak has 
    confirmed this revaluation.  NIST has hedged its position, as one would 
    expect, but they have not said no (again F2F discussions in Dec '19).


    Further you should point out that HMAC needs 2 hash operations to KMAC's 
    single sponge invocation.  This is an important performance 
    consideration in constrained devices.  Even if SHA-256 is marginally 
    faster than KMAC-128 (same strength), it is not twice as good.

    On top of that KMAC as a KDF replaces two or more HMACs (depending on 
    how many key bits needed).  Again a performance gain.

    I would be happy to work with the draft authors on changes in KMAC usage.

    Also NIST is stating that the LWC will conclude by end of 2021.  It 
    behoves Lake to look hard at the LWC finalists that do hashing. This 
    could be saved for a separate draft, depending on expected completion 
    and last call of lake-edhoc.

    thank you for consideration.

    -- 
    Lake mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/lake