[openpgp] changing v5 signature salt size from 16 to 32 octets? [was: Re: lack of agenda items...]

[Daniel Kahn Gillmor <[e-mail]>]

On Thu 2022-11-03 08:32:00 +0000, Aron Wussler wrote:

> In v5 we added a 16-byte random salt prefixing the data when hashing for signature, great idea because if it's unpredictable it can prevent collision attacks.
>
> In SPHINCS+ this is also similarly done in the construction, but it has a variable size depending on the hash output size.
>
> To make randomized hashing coherent with PQC signature schemes I'd like to ask if
>
> (1) it is possible to extend the field to 32 bytes to match other constructions,

Are there any size concerns worth considering here?

The salt needs to be represented in a few different contexts:

 - in the one-pass signature packet
 - in the SaltedHash Armor header for a (LIT SIG)-style signed
   message (non-one-pass), and probably
 - in some sort of RFC 3156-style parameter to enable one-pass
   validation of a signed e-mail message.

base64-encoding the 32-byte value will bring this to 43 characters.

That would make the SaltedHash: armor header 43+13+8 = 64 characters
long, like so:

SaltedHash: SHA3-256:9haH8LirCmteTImei9GQtIHMgJ26zM/uPAoiZepB4cw

That's not implausible for messages of already moderate size, though it
does double the size of the signature itself for small-signature formats
like ed25519.

I should add a note of historical caution about including too much
gratuitous randomness.  tls-extended-random [0] has not aged well [1].

[0] https://datatracker.ietf.org/doc/html/draft-rescorla-tls-extended-random
[1] https://blog.cryptographyengineering.com/2017/12/19/the-strange-story-of-extended-random/

The crypto-refresh revision to RFC 4880 does caution about this in the
"Random Number Generation and Seeding" section.  It might be worth
including pointers to that section in the section where we talk about
salts for v5 signatures.

> (2) it is possible to bind the salt size to the hash function.

Is it the hash function that is relevant here or is it the public key
signature function?  From OpenPGP's perspective, the message is hashed,
and the hash is signed.  In the OPS packet, there is an explicit
indication of the public key algorithm used.  What if we were to tie the
salt size to the public key algorithm, perhaps by adding a column to
Public-key algorithm registry indicating "v5 signature salt size"?

I understand that SPHINCS+ is itself hash-based, so perhaps this is
getting too far into the PQC discussion, but can you give the WG a
summary of how you think binding the salt size to the hash function
would work?  Are you suggesting that the salt should be (for example)
the size of the hash used?  That would make the SaltedHash header long
enough to potentially cause linewraps when, say, SHA2-512 or SHA3-512 is
in use.

         --dkg