[openpgp] Re: pure vs. pre-hash in FIPS 204 and 205

[Falko Strenzke <[e-mail]>]

Forgot to post that one to the list, too...

Am 26.08.24 um 15:43 schrieb Falko Strenzke:
>
> Hi Justus,
>
> Am 26.08.24 um 14:17 schrieb Justus Winter:
>> Hi Falko :)
>>
>> thanks for the explanation.  I think I understand now.
>>
>> Falko Strenzke<[e-mail]> writes:
>>
>>>> On the other hand, if OpenPGP were to use the HashEdDSA variant, we'd
>>>> compute:
>>>>
>>>>     sig = PureEdDSA(PH(Hash(OpenPGP_Hash_Stream)))
>>>>                        ^ This happens in OpenPGP
>>>>                     ^ This is the prehash in HashEdDSA
>>>>
>>>> Which seems not ideal.
>>> This is the point of the misunderstanding. There is no double hashing.
>>> PH(OpenPGP_Hash_Stream) is the only hash that happens.
>> I see.  I guess what contributed to my misunderstanding this is that
>> PH(OpenPGP_Hash_Stream) seems impossible to implement: it combines
>> hashing and signing into one operation, breaking both OpenPGP's model
>> and every existing implementation, therefore, I guess I concluded that
>> PH(Hash(OpenPGP_Hash_Stream)) is the only conceivable way to implement
>> this.
>>
>> For the record, Nettle only implements PureEdDSA.  I can see that the
>> implementation seems to be extensible to HashEdDSA, but this has to be
>> done in the library (i.e. cannot be done by a consumer), and it would
>> require a different kind of interface for signature creation and
>> verification where you can stream the data into.
>>
>> I see that Botan has that kind of streaming interface, but the Rust
>> bindings do not export a streaming interface.  I haven't looked at other
>> libraries.
>
> Switching to HashEdDSA in the PQC hybrids is nothing we currently 
> planned anyway. It would be more consistent to use the pre-hash 
> variant (if we choose it) for both the PQC scheme and the EdDSA scheme 
> together, but this would, as you report for your implementation, most 
> likely bring even further pain points for implementers.
>
> I looked at the implementation of HashEdDSA in Botan. Indeed, it seems 
> that even the C++ interface doesn't allow to compute the hash 
> separately and then sign it. That's too bad.
>> So circling back to your original question, I believe that for
>> implementers requiring a signing algorithm of the pre-hashed variant is
>> a major burden.  Even if all the cryptographic libraries would support
>> the pre-hash variant with a suitable streaming interface (which they
>> don't for EdDSA), we'd have to stuff the signing/verification algorithm
>> into places where we up to now only have hash algorithms.  It is not
>> that it couldn't be done, but since it breaks the mold, it is a hassle.
>
> With a proper interface of the crypto library for the pre-hash variant 
> you shouldn't need a streaming interface. That's the whole point of 
> the pre-hash variant, all the processing can remain as it is: you 
> compute the hash of the message, and when it comes to calling the 
> signing function, you provide this hash as the input, just as for RSA 
> or ECDSA. However, as we've seen it's not guaranteed that a) the 
> library implements the pre-hash variant at all, and b) if it it 
> implements it, it does so in sensible way.
>
> Best regards,
> Falko
>
>> Best,
>> Justus
> -- 
>
> *MTG AG*
> Dr. Falko Strenzke
>
> Phone: [phone]
> E-Mail: [e-mail]
> Web: mtg.de <https://www.mtg.de>
>
> <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
> ------------------------------------------------------------------------
> <https://360-german-security-alliance.de/> 
> <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>
>
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: [phone]
E-Mail: [e-mail]
Web: mtg.de <https://www.mtg.de>

<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
------------------------------------------------------------------------
<https://360-german-security-alliance.de/> 
<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>