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

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Aug 29, 2024 at 1:46 PM Andrew Gallagher <[e-mail]>
wrote:

> On 29 Aug 2024, at 17:21, Phillip Hallam-Baker <[e-mail]>
> wrote:
>
>
> I am also committed to hash-then-encrypt. It is the structure we adopted
> long ago and I don't see a good argument for changing. If we have a 1TB Zip
> file and it already has a SHA-2-512 digest in the checksum, we want to use
> that, not compile another digest. And I think we should use the same
> approach for certificates and assertions.
>
>
> I don’t understand this. Do you mean hash-then-sign? And if so, I’m not
> sure how a zipfile checksum is relevant…?
>

Hash then sign. If you sign the zipfile...

The manifest approach is actually superior though. Especially for OpenPGP
> because we should be signing the content metadata and not just the content.
> A semantic substitution attack is a much bigger threat than digest.
> Constructing a digest is very hard, constructing a PDF that reads as a
> legitimate JPEG is just hard and I can't remember which flip they did but I
> am pretty sure I remember an attack of that type.
>
>
> IMO if we want to sign content metadata in a standardised way it should be
> done at the OpenPGP layer, via e.g. signature subpackets as we have
> discussed previously. This way, it is handled independently of the
> underlying signature algorithms. I don’t think combining these two problems
> makes either one easier to solve.
>

If you only want to do ML-DSA, then just use Prehash and make sure you can
translate from the OpenPGP identifier to the OID. Which really isn't a huge
issue as you already have to do that for RSA.

The manifests issue comes up because we whiffed on Ed25519 and Ed448 and
the pre-hash version doesn't let you pick the digest which really doesn't
fit the hash then sign architecture in OpenPGP. T

8032 tells us: Ed448 is

   2.  Compute SHAKE256(dom4(F, C) || prefix || PH(M), 114), where M is
       the message to be signed, F is 1 for Ed448ph, 0 for Ed448, and C
       is the context to use.  Interpret the 114-octet digest as a
       little-endian integer r.


where for pure:

PH(x)   | x (i.e., the identity function)


and for pre

   Ed448ph is the same but with PH being SHAKE256(x, 64) and phflag
   being 1, i.e., the input is hashed before signing with Ed448 with a
   hash constant modified.


The problem is that when we were designing this, the requirement for
'prehash' was interpreted being you could use the digest algorithm the spec
told you to use to prehash the content so you didn't have to send 3MB of
data to an HSM.

The real requirement for a prehash is you have to be able to sign a digest
that has been precomputed for you using the algorithm they chose.

The reason we got here is that we were following DSA which if you recall
was welded to SHA-1 in a fundamental fashion. But that didn't really end up
kicking us because SHA-1 was our favorite hash algorithm at the time and we
stopped using DSA because the keys were too small before we found out about
SHA-1.


So we don't need to define manifests for ML-DSA, just use Prehash and
specify the OID of the algorithm you used to prevent the downgrade attack,
it is what it is designed for.

We do need to fix Ed25519 and Ed448 for any application that allows use of
any algorithm other than SHA-2-152 for Ed25519 or SHAKE for Ed448 unless
they already use a manifest to perform digest binding.


Simplest distance between the two points is to use the Context input to
specify e.g. "OpenPGP v4.2 with SHA-3-512".