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

Hi Daniel,

Am 05.09.25 um 16:43 schrieb Daniel Huigens:
> Hi Falko,
>
> Thanks for the thorough response. The framework you propose seems 
> sensible to me.
>
> I'll pick on some details re. the persistent symmetric keys draft:
>
> On Thursday, September 4th, 2025 at 14:24, Falko Strenzke 
> <[email protected]> wrote:
>>
>> - define new public key packets, since they can't be used for 
>> encryption or signature verification
>>
> 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?

>> - 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. 
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".

Best regards,
Falko

> Best,
> Daniel
>
> P.S. Aron is on vacation for the coming 10 days, so it may take him 
> some time to respond to the forwarding part.
>
>
> _______________________________________________
> openpgp mailing list [email protected]
> To unsubscribe send an email [email protected]
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: +49 6151 8000 24
E-Mail: [email protected]
Web: mtg.de <https://www.mtg.de>

------------------------------------------------------------------------

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>

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