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

Hello Bob, 

Sorry for slow response. 

Thanks for comments and for your input to this topic! One trigger for bringing in KMAC into this draft in the first place was actually a CFRG thread which you contributed to. At the time we did consider something like what you are proposing in this mail. While it would reduce the number of hash operations it would require quite some changes in the key schedule (see Fig.2 on p.214 of [1] for a not quite up-to-date but nicely drawn figure). Considering the cost for hash operations in comparison to e.g. the public key operations needed we didn't think this optimization warranted a different key schedule for HMAC and KMAC. 

Thanks
Göran

[1] https://www.scitepress.org/Papers/2021/105540/105540.pdf

On 2021-07-30, 21:49, "Lake on behalf of Robert Moskowitz" <lake-bounces@ietf.org on behalf of rgm-sec@htt-consult.com> 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
    Lake@ietf.org
    https://www.ietf.org/mailman/listinfo/lake