Adam Back writes:
The approach of signing encrypted key and using the key to MAC the
data is interesting. It's very similar to what Ian and I proposed in:
Non-Transferable Signatures using PGP, Usenix Annual Technical
Conference, 98, Ian Brown and Adam Back
There's a short summary here:
http://www.cs.ucl.ac.uk/staff/I.Brown/nts.htm
I haven't been able to get through to this site; I'll try again later.
I don't think that so bad. I think a reasonable approach for example
would be to by default non-transferably sign when messages are
encrypted and transferably sign when they are not (which makes sense
as it's probably what you want anyway as you described in a later
message, and with this particular scheme you can't sign without
encrypting).
Well, you can sign without encrypting the message by using the shared
key to MAC the message rather than encrypt it, although you're right
that there still has to be an element of encryption involved, and you
do need to know who the recipient is.
My main concern is not so much with the operational complexity; as you
say, the software could automatically create the right kind of signature
in most cases. My worry is more with the understanding on the part
of the users as to what kinds of security guarantees they are getting.
Descriptions of digital signatures are widely available, and the motivated
user has many sources he can go to in order to learn about how signatures
work.
If we introduce these non-transferable signatures (good name btw) then
there is more possibility for confusion. It's completely different from
a regular signature; for one thing, Alice doesn't even have to type her
passphrase, because her signature key is not used when she creates this
kind of "signature"! Imagine the paranoia that would trigger on the PGP
user lists. In general it's going to increase the explanatory burden
for people who want to understand what the software is doing.
I am also concerned about the security of this specific construction,
Sign_Alice(Encrypt_Bob(K)), MAC(K,Msg), Msg. (Also applies to
Sign_Alice(Encrypt_Bob(K)), Encrypt(K, Msg).) One attack I noticed is
that if Bob accidentally reveals K to an eavesdropper Eve, Eve can replay
the Sign_Alice(Encrypt_Bob(K)) block and replace the Msg with her own.
To defend against this either Bob could keep a list of recently used
K values (and perhaps include timestamps in the signed block). Or of
course he could just be careful about leaking K, but it is an important
consideration for the designer. It would be nice to see some security
proofs for this construction.
Is there an extension of this to the multi-party case? It doesn't
work to use the simple idea of having Alice encrypt K to each recipient
and sign those encryptions, then MAC (or encrypt) the message with K.
The problem is that each recipient learns K, hence any of them might have
created or altered the message body. Each recipient is only convinced
that the message came from Alice or someone on the recipient list.
Logically it seems to me that for this to work the message has to be one
which was constructable either by the signer, or by the collective effort
of all the recipients WORKING TOGETHER. In this way, each recipient
can know that, since he did not collude with the other recipients to
make the message, it must have come from the claimed signer, making
the signature convincing. But outside parties cannot rule out the
possibility that the recipients collectively "forged" the message,
making the signature non-transferrable.
This concept can be applied pretty straightforwardly to the mathematical
key-combining technique, I think (I figured out how to do it once) but
I don't see how to use the simple hash/encrypt trick to accomplish this.
BTW please do not forward this message elsewhere; by our company policy we
are supposed to restrict technical discussion of cryptography to research
oriented forums, and this list counts for that, but not most others.
Hal