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

Yuriy Kaminskiy yumkam at gmail.com
Sat Jan 25 12:05:04 EST 2014


James A. Donald wrote:
> On 2014-01-23 18:55, Kristian Gj�steen wrote:
>> 23. jan. 2014 kl. 00:05 skrev Alexandre Anzala-Yamajako
>> <anzalaya at gmail.com>:
>>
>>> In the public key world, signing ciphertexts not only reveals the
>>> identity of the sender but also allow relay attacks where a guy
>>> intercepts a signed message, strips it from his signature and
>>> replaces it with its own. Depending on the protocol it can be a problem.
>>
>> As usual, this is a well-studied problem. You need only include the
>> sender and recipient identities together with the message, and then
>> EtS and StE are both secure.
>>
>>     On the Security of Joint Signature and Encryption. Jee Hea An,
>> Yevgeniy Dodis, and Tal Rabin. EUROCRYPT, volume 2332 of Lecture Notes
>> in Computer Science, page 83-107. Springer, (2002).
>>
>> Obviously they have different properties: EtS ciphertexts reveal the
>> sender (which may be both desirable or undesirable or both), while StE
>> ciphertexts do not (probably not sufficient on its own).
>>
>>> I think the encrypt-sign-encrypt solution solves both of those problems
>>
>> It is at best an inefficient solution. (I have not verified that it is
>> a solution.)
>>
> 
> 
> Signing bad, except in few special cases.  Authentication good.
> 
> To encrypt, must establish a shared secret.  Derive encryption and
> authentication shared secrets, and use the authentication secret for a mac.

MAC prove that message was produced by *any* of participants that have access to
the shared secret (and can be validated only by people that have access to this
shared secret).
Works perfectly with *one* participant (you store encrypted and MACed data on
untrusted medium; then you retrieve your data [on trusted system], and verify
MAC to ensure they are still intact).
Still works with two participants (if only Alice and Bob knows shared secret,
and Bob knows he is not author, it must be Alice). That is, unless Bob private
key leaked (pretty bad for Bob anyway, but still with MAC he is *more* pwned
than with signatures).
Does not work with *more than two participants* (Alice, Bob and Charlie know
shared secret and thus can generate and validate MAC; who was author of message,
Alice or Charlie?).
And, of course, cannot work at all with *undefined* number of participants (to
verify signature, you need public key, there are no problem with distributing
public key to random people; to verify MAC, you need *secret* key, there are no
way you can safely share secret key with random people).

> If need to associate ephemeral public key with sender's permanent public
> key, wrap another shared secret that involves the permanent public key
> inside the message.

You mean, "sign her ephemeral key on permanent key"? LOL.
(And still *MAC completely useless with more than two participants*.)
And, as said above, to ensure encryption is intact, you need to sign *recipient
key* rather than *(ephemeral) sender key*.



More information about the cryptography mailing list