Hi Orie,
I would suggest defining algorithm identifiers for both the regular and
pre-hash algorithms. That will make explicit what is happening, which I
suspect will serve us well. Not doing this would cause an endless loop of
repeating this same discussion over and over again. ;-)
-- Mike
From: [email protected] <[email protected]> On Behalf Of Orie Steele
Sent: Tuesday, August 27, 2024 9:32 AM
To: Phillip Hallam-Baker <[email protected]>
Cc: Falko Strenzke <[email protected]>; pqc-forum
<[email protected]>; cose <[email protected]>
Subject: Re: [pqc-forum] Question regarding pure vs. pre-hash ML-DSA
We're working on a COSE draft that tries to address a similar issue, but
generically for traditional digital signature schemes as well:
https://cose-wg.github.io/draft-ietf-cose-hash-envelope/draft-ietf-cose-hash-envelope.html#section-4-2.2.1
Just for the sake of separating out terminology, consider the following:
- ECDSA with secp256r1 and SHA-256 HASH (we'll call this ESP256)
- ESP256 used to produce a COSE Sign1 (we'll call this cose-sign1-with-esp256)
- ESP256 used to produce a "hash envelope" (we'll call this
cose-sign1-hash-envelope-with-esp256)
Even in the case where "cose-sign1-with-esp256" and
"cose-sign1-hash-envelope-with-esp256" sign the same payload, which could be
the length of a SHA-256 hash, they can be distinguished by the presence of
protected headers.
It can be useful to consider a remote KMS interface, where the message needs to
be conveyed to the signer in order for a signature to be produced.
This is confusing to think about when you have "pre-hash" in both the raw
crypto layer, and the protocol layer.
I like to think about this problem from the perspective of what a client can do.
Let the message / payload be a 1 TB LLM model.
# Case 1
With HashML-DSA-65-SHA-256 and "normal cose-sign1" the client can do the
following:
Set the protected header to be { alg: HashML-DSA-65-SHA-256 } // crypto layer
pre-hash
Construct the Sig_structure as defined in
https://datatracker.ietf.org/doc/html/rfc9052#section-4.4-4
Result is Sig_structure = [ context : "Signature1", protected_header: bytes,
payload : 1 TB LLM Model ]
Hash the Sig_structure with SHA-256
Send the result to a remote KMS...
A sha-256 hash moves over the network.
Server does not see protocol metadata / Sig_structure... cannot enforce policy
on it.
Client receives a raw HashML-DSA-65-SHA-256 signature...
Construct a complete cose-sign1
# Case 2
With ML-DSA-65 and "COSE Hash Envelope" the client can do the following:
Hash the 1 TB payload to produce a sha-256 hash.
Set the protected header to be { alg: ML-DSA-65, payload_hash: SHA-256 } //
protocol layer pre-hash
Construct the Sig_structure as defined in
https://datatracker.ietf.org/doc/html/rfc9052#section-4.4-4
Result is Sig_structure = [ context : "Signature1", protected_header: bytes,
payload : bytes (sha-256 hash) ]
Send the result to a remote KMS...
Protocol data structure moves over the network, and is larger than sha-256 hash.
Server sees the protocol metadata / Sig_structure... can enforce policy on it.
Client receives a raw HashML-DSA-65 signature...
Construct a complete cose-sign1
# Case 3
With HashML-DSA-65-SHA-256 and "COSE Hash Envelope" the client can do the
following:
Hash the 1 TB payload to produce a sha-256 hash.
Set the protected header to be { alg: HashML-DSA-65-SHA-256, payload_hash:
SHA-256 } // crypto and protocol layer pre hashing
Construct the Sig_structure as defined in
https://datatracker.ietf.org/doc/html/rfc9052#section-4.4-4
Result is Sig_structure = [ context : "Signature1", protected_header: bytes,
payload : bytes (sha-256 hash) ]
Hash the Sig_structure with SHA-256
Send the result to a remote KMS...
A sha-256 hash moves over the network.
Server does not see protocol metadata / Sig_structure... cannot enforce policy
on it.
Client receives a raw HashML-DSA-65-SHA-256 signature...
Construct a complete cose-sign1
...
See Section 5.4 of FIPS204
"""
If the content to be signed is large, hashing of the content is often performed
at the application level.
For example, in the Cryptographic Message Syntax [29], a digest of the content
may be computed, and
that digest is signed along with other attributes. If the content is not hashed
at the application level, the
pre-hash version of ML-DSA signing may be used.
In order to maintain the same level of security strength when the content is
hashed at the application level
or using HashML-DSA , the digest that is signed needs to be generated using an
approved hash function
or XOF (e.g., from FIPS 180 [8] or FIPS 202 [7]) that provides at least 𝜆 bits
of classical security strength
against both collision and second preimage attacks ...
"""
In the example I gave above, I used SHA-256 for everything, but I could have
used SHAKE256 and SHA-256 strategically to work around constraints on the
client or the server.
This is noted at the top of Section 5.4:
"""
For example, the platform may require hardware support for hashing to achieve
acceptable performance but lack
hardware support for SHAKE256 specifically.
"""
Regards,
OS
On Tue, Aug 27, 2024 at 10:30 AM Phillip Hallam-Baker
<[email protected]<mailto:[email protected]>> wrote:
You can indeed pass the digest directly into pure. The issue being that it is
unsafe to do so, an attacker can perform a digest substitution attack on it.
Consider the case where the application supports a hash which has been broken
to the extent that they can create any digest output they like - MD-BORKED
Queen Alice decides to knight Bob, writes out a declaration to that effect,
hashes it with SHA-2-512 and posts it to the gazette.
Mallet takes the signature, writes out a death warrant for Bob and uses the
MD-BORKED manipulation code to create a digest that matches that of the
original message. Instead of arriving to find the Queen holding a sword to
confer the accolade, Bob finds the headsman holding an axe.
That is why it is always necessary to bind the digest type into the signature
if a pre-hash is used.
Pure should only be used on the message content itself or on a manifest
structure which includes the digest value.
So for example, a DARE signature on a chunk appended to a sequence typically
contains the following information:
* Digest algorithm used to digest the content
* Digest value over the content
* Digest algorithm used to create the Merkle Tree
* Apex value of the Merkle tree
* Witness value showing demonstrating the signer knew the encryption key
* Application context identifier
Those values are carried in a separate JSON manifest which once I have finished
the code will be signed with ML-DSA pure and with Ed448 pure with the context
string 'DARE manifest'.
On Tue, Aug 27, 2024 at 7:04 AM Falko Strenzke
<[email protected]<mailto:[email protected]>> wrote:
Dear NIST team,
in FIPS 204, Section 5.4, I read
If the content to be signed is large, hashing of the content is often performed
at the application level.
For example, in the Cryptographic Message Syntax [29 ], a digest of the content
may be computed, and
that digest is signed along with other attributes. If the content is not hashed
at the application level, the
pre-hash version of ML-DSA signing may be used.
How is the last sentence to be understood? If the content is not hashed at the
application level, that sounds to me as if it can be fed into the pure
signature generation or verification routine directly. After all, ML-DSA
signature generation and verification is single-pass over the message, if I am
not mistaken.
On the contrary, my understanding of the pre-hash variant is that it is
specifically for those cases, where the protocol is bound to compute a hash
before it can access (or decide on) the signature generation or verification
function. The last sentence of the quote, however, seems to suggest that the
pre-hash variant is merely a convenience function to combine the hash
computation with the signature computation.
Can you please clarify?
Best regards,
Falko
--
MTG AG
Dr. Falko Strenzke
Phone: +49 6151 8000 24
E-Mail: [email protected]<mailto:[email protected]>
Web: mtg.de<https://www.mtg.de/>
[cid:[email protected]]<https://www.linkedin.com/search/results/all/?fetchDeterministicClustersOnly=true&heroEntityKey=urn%3Ali%3Aorganization%3A13983133&keywords=mtg%20ag&origin=RICH_QUERY_SUGGESTION&position=0&searchId=d5bc71c3-97f7-4cae-83e7-e9e16d497dc2&sid=3S5&spellCorrectionEnabled=false>
Follow us
________________________________
[cid:[email protected]]<https://360-german-security-alliance.de/>
[cid:[email protected]]<https://www.itsa365.de/de-de/companies/m/mtg-ag>
MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde
This email may contain confidential and/or privileged information. If you are
not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised copying
or distribution of this email is not permitted.
Data protection information: Privacy
policy<https://www.mtg.de/en/privacy-policy>
--
You received this message because you are subscribed to the Google Groups
"pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
[email protected]<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/e619b550-178a-4816-8605-8ffb3d0e9c06%40mtg.de<https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/e619b550-178a-4816-8605-8ffb3d0e9c06%40mtg.de?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
[email protected]<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMm%2BLwixu%3D7wLpOu%3D3eZAaj0BZSrDcz%2B_k6%2BAeKrRemY-j8wig%40mail.gmail.com<https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMm%2BLwixu%3D7wLpOu%3D3eZAaj0BZSrDcz%2B_k6%2BAeKrRemY-j8wig%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries<http://www.transmute.industries/>
[https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>
--
You received this message because you are subscribed to the Google Groups
"pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
[email protected]<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAN8C-_LWNnmiNSdmpkB%3D58HuhqqtbBZdgo876dikA_qJvZ97oA%40mail.gmail.com<https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAN8C-_LWNnmiNSdmpkB%3D58HuhqqtbBZdgo876dikA_qJvZ97oA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
