Re: [openpgp] Intent to deprecate: Insecure primitives

[ianG <[e-mail]>]

On 22/03/2015 09:18 am, Andrew Skretvedt wrote:
> I am a curious onlooker with no operational affiliation to the business
> of this list (and normally silent), with an observation/question at this
> point in this thread:
>
> Is it considered best practice now to encrypt, then sign?


What is the meaning of 'sign'?  Do you mean here to sign as if you are 
affirming that it is you sending the message and you might consider this 
a digitial signature over your words?  If so, then you should sign 
before encryption, and it's a good idea to do that in cleartext/inline 
format.

Alternatively, are you signing to put a message authentication code over 
it so that it is securely delivered?  In which case, it is better 
practice to encrypt then sign.  While this is not a totally solid rule 
(it depends on the protocol details) I think this is safe in OpenPGP.


> I think I
> heard somewhere that SSL/TLS does it the other-way-round and has thereby
> innocently created certain problems. GnuPG allows these operations to be
> combined on the command line, and then I don't know in what order they
> actually occur.


Yeah, the research on attacking the order came after these things were 
thought about in groups.  But bear in mind there is a bit of a 
difference between SHA-style HMACs and RSA-style digsigs.


> If you receive an encrypted and signed message, and best practice would
> be to, in reasonable time, decrypt from wire-format and re-encrypt to
> local format for PFS (which seems to me a really sound policy, given
> modern experiences, and might be just as easy as leaving it to your
> full-disk-encryption system where you store your mail), might you lose
> the ability to provably authenticate the messages in your archive? I can
> think of situations where one would not want to lose this ability (e.g.
> some sort of dispute or legal proceeding).


Yes, that's complicated.  Suffice to say that the need to prove that you 
received a message and didn't change it is way-over-thought in the tech 
world.  99.999% of it is about having the message [1].  So let's solve 
the real problems before we make up problems...


> Perhaps if they get signed, then encrypted, this problem goes away. But
> then why /should/ one do these two operations in one order in the e-mail
> context, but perhaps the opposite order in others? (Perhaps I betray my
> ignorance at this point.)


The reasons are historical.  Back then, nobody much knew the difference 
between authentication and signing.  Later on, HMACs were developed for 
the message integrity.  And signing-as-intent fell out of favour because 
nobody wanted it.

So likely a new message suite will include an AE or Authenticated 
Encryption suite, which will handle all the message integrity.  That'll 
be stripped off, and the message will be delivered plain.  Then the 
software will say who it comes from.  If there is a need to keep that 
proof then we'll likely need another tag to attach to the plaintext message.

iang



[1] as long as we're talking words.  If we're talking transactions then 
a common dispute is having different 'recollections' of the transaction, 
and having good MAC'd copies is what we want to achieve.