Re: [lamps] [EXTERNAL] Re: LAMPS Virtual Interim in Sept. 2022

ScottF points out that this discussion is also relevant to SPHINCS+ as it also prefixes a string to the message before signing.

Uri,

Thanks.

Yes, (I assume) the hash-with-nonce step is a defense against collision attacks *given that collision attacks exist in the chosen hash function*. A good clarification to add. It would be good to get clarification from someone more familiar with the Falcon / Dilithium design to confirm that this is what that step is there for, and how important it is to not weaken it.

A few more thoughts about security of externalizing the hash:
* For Dilithium the nonce is the public key. Not sensitive.
* For Falcon the nonce is `r = random()`. Using an RNG outside the crypto module will likely be a no-go for FIPS. Perhaps crypto modules will need to provide 'r' to the caller so that it can perform the hash?
* For both algorithms, as you say, you lose guarantee about which message was hashed, but this should map to the security models we use with hash-then-sign RSA / ECC today -- ie if you don't trust the layer doing the pre-hash, then you have bigger problems.

---
Mike Ounsworth

-----Original Message-----
From: Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu> 
Sent: September 16, 2022 11:58 AM
To: Mike Ounsworth <Mike.Ounsworth@entrust.com>; Russ Housley <housley@vigilsec.com>; LAMPS <spasm@ietf.org>; cfrg@irtf.org
Cc: Tim Hollebeek <tim.hollebeek@digicert.com>
Subject: Re: [lamps] [EXTERNAL] Re: LAMPS Virtual Interim in Sept. 2022

Mike Ounsworth wrote:
> Could I get a slot at the LAMPS interim to discuss the hash-then-sign issue for Dilithium and Falcon?

I think this issue is worth discussing.

> Issue summary:
>
> - Needing to stream your entire message to your crypto module is dumb
> (think streaming an entire firmware image to your network HSM for code-signing,
> or to your TPM for secure boot validation; yuck).

I'm not sure I agree here - if you sign a hash of something, you can't be sure it's a hash of what you wanted to sign.

> - You want to send just a hash.

Majority (but not all!) of the cases are exactly as you say - sending just a hash...

> - Both Dilithium and Falcon have, as their first internal step' a hash of the
> message prepended with a nonce (the pubkey for Dilithium, and a random r for Falcon),
> I assume in order to block pre-computed collision attacks.
> - If you, for example, do SHA256(m) before calling Dilithium.sign(), then
> you have re-introduced that collision attack.

This assumes one can find collisions in the hash function used. For SHA2 and SHA3 it's a tall assumption.
AFAIK, the main reason SHA3 hasn't superseded SHA2 at this point (despite that SHA3 is cryptographically 
nicer and better) is that SHA2 proved to be "strong enough".

> - You can externalize that first hashing step of the Dilithium / Falcon sign / verify
> algs outside of the crypto module without breaking interop, but doing so will need to
> be mentioned in the standards, and will need security review.

Offhand, I doubt this can be secure...

    -----Original Message-----
    From: Spasm <spasm-bounces@ietf.org> On Behalf Of Russ Housley
    Sent: September 8, 2022 3:21 PM
    To: LAMPS <spasm@ietf.org>
    Cc: Tim Hollebeek <tim.hollebeek@digicert.com>
    Subject: [EXTERNAL] Re: [lamps] LAMPS Virtual Interim in Sept. 2022

    WARNING: This email originated outside of Entrust.
    DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

    ______________________________________________________________________
    A few things for tomorrow have come up, which prevented us from picking that date.  So, we care going to hold the LAMPS Virtual Interim on 19 Sept. 2022 at 9:00 Eastern.

    We already have two agenda items.  Please let us know if you want to present on another topic.

    Russ & Tim

    > On Aug 24, 2022, at 12:07 PM, Russ Housley <housley@vigilsec.com> wrote:
    >
    > Two agenda topics did not get covered at IETF 114:
    > - draft-perret-prat-lamps-cms-pq-kem
    > - draft-kario-pkcs12-pbmac1
    >
    > There may be other topics that have progressed enough to need some discussion.
    >
    > Tim and I think that 60 minutes will be enough to to cover these topics.
    >
    > Please fill out the following poll to help us find the best time for the meeting:
    > https://urldefense.com/v3/__https://doodle.com/meeting/participate/id/dN9x14vb__;!!FJ-Y8qCqXTj2!ZDZM1GgJw-UNsq7N5jg8dUYx470A6dFZyNqiwQrJRoRhH73AH0b35-Kl0QnYNyJLmi_5VMh0JJP1FOEFWwmtfYwZA0K4$
    >
    > Russ & Tim
    >
    >
    > _______________________________________________
    > Spasm mailing list
    > Spasm@ietf.org
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!ZDZM1GgJw-UNsq7N5jg8dUYx470A6dFZyNqiwQrJRoRhH73AH0b35-Kl0QnYNyJLmi_5VMh0JJP1FOEFWwmtfZyACGq2$

    _______________________________________________
    Spasm mailing list
    Spasm@ietf.org
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!ZDZM1GgJw-UNsq7N5jg8dUYx470A6dFZyNqiwQrJRoRhH73AH0b35-Kl0QnYNyJLmi_5VMh0JJP1FOEFWwmtfZyACGq2$
    Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

    _______________________________________________
    Spasm mailing list
    Spasm@ietf.org
    https://www.ietf.org/mailman/listinfo/spasm