[openpgp] Re: persistent symmetric key asymmetry between signing/verifying and encryption/decryption

[Daniel Huigens <[e-mail]>]

Hi dkg,

> You're assuming that the attacker isn't the person who sent the message,
> right?
> 
> If you're using this as an integrity mechanism, it seems like it fails
> against (at least) the original sender, (...)

Yeah. We're talking about symmetric cryptography here, so the "sender"
and recipient should either be the same person, or trust each other.
If the sender and recipient are different people, and the sender
modifying the message later is within the threat model, then you
cannot achieve security with symmetric crypto and need asymmetric
crypto instead.

> and anyone else who legitimately
> received a copy of the message (and therefore knows the session key
> because they got it from their own PKESK).

Yeah, this is what I tried to say when I wrote:

  If however you encrypt a message to yourself with a PSK and to someone
  else with an asymmetric key, and you don't sign the message, then the
  other person has access to the session key, and could potentially
  (collude with an attacker to) modify your copy in storage. That is
  indeed quite surprising. Then again, in that scenario you probably
  want to sign the message anyway - but you then still need to remember
  to verify that signature when reading your own copy, too.

> > If you need some metadata, you could store that inside the encrypted
> > data (since in this scenario, you probably have control over the
> > plaintext format / data type). We also still have the open question
> > of encryption context [1] that could be helpful in some scenarios.
> 
> But do we need an encryption context to be able to use this
> successfully? it would seem unwise to add new work items that would
> block the PSK work.  i'm trying to figure out how to safely use the
> proposed mechanism with what we already have, and provide adequate
> guidance.

I wasn't trying to propose that we block PSK on that, no.
As long as we don't have additional data, you need to include
the context in the (signed and/or) encrypted data; that's true
both for asymmetrically and symmetrically signed/encrypted data.
Being able to use additional data instead will then be a size
improvement rather than unblocking any use cases. 

> > What is potentially possible, though, is replacing the entire message
> > with an asymmetrically encrypted one. So, in this specific scenario,
> > the consumer would need to check that the message was either signed
> > or encrypted using a PSK (and know that they only encrypted it to
> > themselves).
> 
> It's this temptation to an "either signed or encrypted" shortcut that
> makes me pretty wary.  For one thing, we don't have a clear way to model
> this yet.  when trying to decrypt a ciphertext with a variety of secret
> key material, different implementations vary in the order in which they
> trial decrypt, and how (or even whether) they report which key material
> was used for a successful decryption.
> 
> How would the implementation even know that they only encrypted it for
> themselves?

I think it could be reasonable for an OpenPGP implementation to report
whether the message was symmetrically encrypted. Then, whether that
means anything for the security model of the application is very
application-dependent; only the application can know who has access
to the key.

> Furthermore, how would they know when they did the encryption?  there's
> no "signature creation date" available.

If this is something the application cares about, it should be included
in the plaintext. This is also true for asymmetrically encrypted messages,
strictly speaking, since it's not required to have a signature either,
and even if there is one, the message isn't guaranteed to have been
signed and encrypted at the same time (especially in the absence of
the Intended Recipient Fingerprint subpacket).

> i think given all the different ways that this kind of
> shortcut could fail, we're probably better off giving guidance to avoid
> the shortcut.

I'm not fully sure I agree in general but we should definitely be clear
about the scenarios where it's safe to do so and where it's not, indeed.
I'll propose some guidance.

Best,
Daniel