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

Hi, all.

On 09/09/2025 00:28, Heiko Schäfer wrote:
> 
>> A) Forwarding
>>     1. Define new algorithms; reuse private key and PKESK packets
>>     2. Define a new key packet and a new FKESK packet
>>     3. Define a new FKESK packet, reuse the private key packet
>> B) Persistent symmetric keys
>>     1. Define new algorithms; reuse private key, PKESK and signature
>>        packets
>>     2. Define all new packets
>>     3. Define a new key packet, reuse other packets, also define new
>>        algorithms or the special value 0
> 
> To recap, for Persistent symmetric keys (B), I argued in favor of B3.

...

> Regarding Forwarding (A), I prefer A1 (or alternatively A3).

...

> My conclusion is that there is no strong argument for introducing a new 
> ESK type for either of the two formats.
Sorry, I'm late to this party too!

I'm in broad agreement with Heiko, although I'm tempted to go further 
and rule out A3. I don't see a convincing argument in favour of an FKESK 
packet - if you don't understand the forwarding algorithm, or you don't 
have access to the appropriate key material, then I believe the worst 
case scenario is decryption failure.

But I'd like to think out loud for a moment.

The forwarding application would need to ensure that it called the 
library API in "forwarding" mode rather than "decryption" mode. The only 
question I have would be whether calling the API in the wrong mode could 
open an attack vector.

For example, let's say Alice sends an email to the remailer, who then 
forwards to Bob.

1. Can Bob (or Mallory) achieve a reduction in security by passing the 
ciphertext that Bob receives back through the remailer and tricking it 
into re-forwarding it?

2. Is there a way that Bob or Mallory could process the received 
ciphertext using key material to which they have access, which would 
make (1) more effective?

If either of the above attack scenarios were possible, framing the 
ciphertext in a different ESK would not prevent it. But if this were a 
serious risk, perhaps we could use key commitment to make the 
re-forwarding fail?

A

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