[Cryptography] Does PGP use sign-then-encrypt or encrypt-then-sign?

[ianG]

On 22/01/14 00:11 AM, Tony Arcieri wrote:
>> Some even suggested doing s-e-s, possibly with different signing keys.
> 
> 
> Wouldn't it make the most sense to sign-then-encrypt-then-MAC (with the
> latter ideally handled by an authenticated encryption mechanism)?


First you need to establish what the sig is.  Is it a MAC, for
protecting the message, or is it a semantically interesting token over
the contents, aka a signature?

One of the architectural flaws of PGP, and competitors like S/MIME, is
that the signature is a cryptographic component with no implied semantic
meaning or purpose.

One needs to go back to the theory of what a signature is, and decide
ones purpose.  In short a signature is a token that is placed over a
document to signify or memoralise an agreement of something like
sighting or contract or written-by or an endearment.

However a digsig in cryptography can sometimes mean that signature
concept above, and it can sometimes claim agreement, or it can mean a
MAC to protect a packet.

Now, typically, in OpenPGP we have preferred to use a cleartext
signature over the contents to do that human signing component, and a
detached digitally preserved signature for message purposes (coz if it
is detached it matters less if it gets lost).  But this isn't written
anywhere!  In practice, then, detached becomes a MAC so it is better off
in technical terms being part of an authenticated encryption suite, and
encrypt-then-MAC is more popular if we got our choices again.  But,
again, because it is a digsig, it also then reveals who is sending the
message, so that's a consideration for those who think mass surveillance
is a real threat.

In short, there is no easy answer, because of these issues.  You can do
whatever you feel comfortable with ...

> What's the value in being able to verify a signature without decrypting?


Well, some think that this makes it easy to avoid a DOS attack.  You
only verify the signature against some expected sender, and if it fails,
you throw it away.  This doesn't make a lot of sense in normal email
mechanics tho.

Also, the email clients have typically (and stupidly) decided that the
signature should be checked against the email address of the sender.
Especially so in S/MIME, you can't use one email address to send a
signed email from another ... because it can check and so it does. Just
another reason why S/MIME fails to deliver and GUI clients have had
trouble.  What they should do is clearly show who the sender of the
inner envelope is, and ignore the sender of the outer envelope.  Then
we'd be a lot happier ...

>  It
> seems like if you can do that then anyone can tie a signature to a
> particular message even if they can't decrypt it, which seems like a
> drawback to me.


yep.  Which is why more advanced protocols these days expect to use
ephemeral keys to do the MACs and encrypts, and strive for PFS or
protocol forward security.



iang