Authenticated, Quantum-resistant GPG2?

Question

GPG2 does not provide authentication. It still uses SHA-1 by default. It does not seem to get any stronger as time goes by.

If one were to pass a randomly-generated symmetric key (from a TRNG) over the

entire encypted and signed GPG data block + HMAC of that GPG data block

would there be any advantage, by a computionally unbounded adversary, to forge a message because they know the underlying structure of the GPG message in detail? Let's say they have known plaintext. Will they be able to flip any bits without the receiver knowing?

So, the user employs GPG2 normally, let's say with RSA and then AES-256 and SHA-512 to encrypt and sign a message. Then the user burns some of the key pad material with the HMAC, using SHA-512. The symmetric key is just as long as this concatenated block. The symmetric key material has already been shared in a secure manner, of course (an OTP).

Let's say the adversary knows the entire plaintext. Will they be able to flip any bits without the receiver knowing; that is, at better odds than what the security of the HMAC promises? I think not, but I would enjoy hearing an expert opinion.

Answer 1

GPG doesn't use post-quantum signatures, so any current implementation of GPG would be unable to provide such security; regardless of the hashing algorithm used.

However, let's assume we have post-quantum signatures in our GPG implementation:

If the hash is sufficiently large, and the hash itself is secure, an attacker not knowing the HMAC key would be unable to forge a message. The issue is, for a quantum computer to be unable to do this, the hash must be at least 512 bits long.

For quantum computers a 512-bit hash behaves (approximately) like a 256-bit hash does on classical computers; while the birthday paradox states that even on classical computers a 256-bit hash ensures only 128 bits of security.

Note: for those who care, a 512-bit hash would behave with slightly more security than a 256-bit hash would for classical computers; the bits of security is relative to the cube-root of $2^k$ (where $k$ is the hash's bit length), not the square-root of the square-root.

Also, the HMAC key must be able to provide (ideally) 128 bits of security, in order to not be compromised by any attack; this applies to classical computers, as well. That means, the HMAC key must act as a 256-bit key to not be broken. This means you should choose a secure password, if you use a password for the HMAC key... But you already knew that.

Once the HMAC key is broken, the security of the hash reverts to the security of the underlying hashing algorithm.

The security of a signature depends only partly on the hash. The rest is up to the signature algorithm; since a weak signature scheme would allow me to sign whatever I want, anyway.

But my real question is "why do you think HMAC is a good idea for a signature scheme?" Doing this would allow only the people with knowledge of the HMAC key to verify signatures; and as such, anyone able to verify messages would be able to forge messages the same as a normal signature scheme.

Another note: You only HMAC the already-signed message. As such, the ability to forge signatures is unaffected; since forging a signature doesn't require the attacker to change the signature, just to collide the signature, which will inevitably lead to the same HMAC as well under your scheme, effectively removing the HMAC's security from the question.