[openpgp] Re: Algorithms vs packets in forwarding and PSK

Hi Falko,

On Monday, September 8th, 2025 at 06:58, Falko Strenzke <[email protected]> wrote:

> Hi Daniel,
>
> Am 05.09.25 um 16:43 schrieb Daniel Huigens:
>
>> The current draft doesn't allow public key packets to be used with persistent symmetric key algorithms at all, since there isn't any use for them. Do you think that should change?
>
> It doesn't? Then I don't understand [Table 1](https://www.ietf.org/archive/id/draft-ietf-openpgp-persistent-symmetric-keys-01.html#table-1) and the [subsequent passage](https://www.ietf.org/archive/id/draft-ietf-openpgp-persistent-symmetric-keys-01.html#section-5-5):
>
> "As the secret key material is required for all cryptographic operations with symmetric keys, implementations SHOULD NOT use symmetric algorithm IDs in Public-Key Packets or Public-Subkey Packets"
>
> It's declared "SHOULD NOT" and not "MUST NOT". What do I misread?

Ah yeah, you're right, I misremembered. The reason it says SHOULD NOT rather than MUST NOT is mainly just for the specific case where you have a data structure or database schema that requires a public key to be there, but they are not intended to be used for anything as.. they don't have any use.

If we decide that we don't care about that case, we could also strengthen this into a MUST NOT.

Beyond that, the values in Table 1 are there primarily to indicate the public algorithm-specific values; those still need to be there even if we forbid the use of these algorithms in public key packets, as the secret key packets also contain the public algorithm-specific values.

(Though, that can change if we define a new persistent symmetric key packet, of course.)

>>> - define new "MAC" packets: a MAC (or the authentication feature of AEAD) is not equivalent to a public key signature. It doesn't provide non-repudiation. Further, any user from a group that shares the same MAC key can forge "signatures" for any member of the group. Accordingly, as I argued in my review [3] of [2], receiving clients might have to treat MACs different than public-key signatures when displaying messages. This seems to suggest that new packet types are needed.
>>
>> I want to note that this argument is somewhat specific to the scenario when you're sharing persistent symmetric key material between multiple users. I'll concede that that may be useful, though it wasn't originally the use case I had in mind, but I'm not sure if we should then base the decision to define a new packet on the semantics in that use case alone.
>>
>> Beyond that, the semantics are the same if you share an asymmetric private key in a group of users, no? You lose non-repudiation in that case, too. So I don't think this argument is actually specific to symmetric keys.
>>
>> (The only difference is that since there's no public key, you might get tempted to share the private key, but then it's the act of doing so that changes the security properties, not the fact that it's a symmetric key.)
>
> Certainly you can take on this point of view, as long as you preclude the use of the symmetric keys for communication. But if the draft allows the keys to be used for communication, then it should also become clear to the implementer how that use case should be handled in the application. So the two options that I see are:
>
> - forbid the use of HMAC for communication
> - define how HMAC signatures should be displayed
>
> It seems to me that contrary to AEAD, HMAC doesn't really seem very useful for communication. May forbidding it is the simplest solution.

I agree that HMAC isn't particularly useful for communication, but on the other hand I'm not sure it needs to be specifically forbidden, or what that would mean, exactly. Let's say you have a small team / group of people that shares a private key, and normally signs their emails (asymmetrically) with the team name ([email protected], let's say), but then for drafts "signs" them asymmetrically using an HMAC key, so that the other team members can authenticate the data and continue editing the draft if necessary. Does that count as communication or no? Perhaps the simplest is to say no.

> For AEAD, in principle the same question arises, namely whether to indicate an AEAD-only-encrypted message as signed. I think the answer should be "no".

It depends who you want to indicate the message as being signed/authenticated by, IMHO. In the above scenario, let's say a team member of [email protected] stores a draft email encrypted using AEAD with a key shared with the team. Then it's perfectly fair to say that the message is signed/authenticated by [email protected], because that encompasses all people that have access to the key, so there's no possibility for confusion. (And if the message was asymmetrically signed with a shared key, it wouldn't change the semantics.)

If I create a symmetric key under the name "Daniel" and share it with you, and you sign or encrypt a message with it, then it's confusing if it shows as authenticated by me. However, if I create a symmetric key under the name "Daniel & Falko" for the purpose of communication between us, then there's no confusion.

And again here, the semantics change not because the keys are symmetric, but because we're sharing a key (though you could argue that's only a sensible/beneficial thing to do when the keys are symmetric).

So, rather than forbidding or allowing (and giving guidance about) using symmetric keys for communication, I would give some guidance about what happens when you share a private (asymmetric or symmetric) key between multiple parties, and the implications that has on verification of HMAC signatures and authentication of AEAD-encrypted data.

Best,
Daniel

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]