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.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp