Now that the rush is off for PGP getting pgp 3.0 lib out, perhaps I
could repeat my rant and generate some interest amongst the PGP Inc
people in thinking about adding support for a couple of privacy
features.
Transferable non-repudiation is actually not usually a desirable
property for digital signatures from a grass roots privacy point of
view. All you really want is for the person receiving your mail to be
convinced that it came from you. This does not mean that you would
like your recipient to be able to reveal your email to any third
parties and prove to them also that you wrote it.
(Note, to make clear we are talking about the same thing, some people
call non-transferable signatures "repudiable signatures".)
The transferability of non-repudiation is not in the interests of the
author of an email. Say you express some unpopular opinions on a
mailing list, or in what you thought was private email, you probably
don't want people who are trying to cause trouble for you to be able
to prove to a high degree of confidence that you authored the disputed
content.
Examples might be that you made some extremely negative comments on
GAK, or opined that you wouldn't be that upset if a nuke took out
washington DC, or that someone posted some private email that you
would have preferred was not made public.
The situation also arises in companies, where it is not a that
uncommon situation that an off the cuff comment made in email has come
back to haunt the company, when the recipient's company takes the
email and uses it as a basis for a court suit.
With a non-transferable digital signature, you would use
non-transferable signatures for normal email, and only use
transferable email if you particularly wanted to make a legally
binding statement.
Non-transferable email for maximum deniability of authorship should
really be delivered via remailers, otherwise mail logs by third
parties, or of the sending parties may be used to attempt to prove
authorship.
Here's a way to do non-transferable signatures with RSA:
Alice sending Bob a signed email. We want:
( X ^ A_pub ) xor ( Y ^ B_pub ) = hash( message )
Alice chooses random Y, and computes X:
X = [ ( Y ^ B_pub ) XOR hash( message ) ] ^ A_pri
Now the non-transferable digital signature is X and Y.
To verify the signature the recipient checks that:
X ^ A_pub XOR Y ^ B_pub = hash( message )
The signature is not transferable because Bob could also produce that
same signature with knowledge of B_pri, for Bob X is a random number,
and Y is calculated:
Y = [ ( X ^ A_pub ) XOR hash( message ) ] ^ B_pri
(I would put in an acknowledgement here with the algorithm, but I'm
not sure the acknowledgee would thank me, re ITAR/EAR).
There are a couple of technicalities with the above method:
i) You have two parts to the message X and Y, you would want to place
these packets in random order. Or at least allow the software to put
them in the other order. (If author comes first always, there is less
deniability).
ii) You should choose Y to be in the range 0..B_pub - 1, otherwise you
leak information about who the author is. The more signatures the
less deniability you have left as the information is accumulated.
iii) You need to decide some padding rules to cope with different
sized keys.
Creating a non-transferable DSS signature is left as an exercise for
the reader :-)
That is I can't see an easy way to do it right now.
Also it's going to be harder to design a protocol to allow one to
create a non-transferable signature where Alice has a DSS key and Bob
an RSA key.
Next post is another old rant about building in stego support.
Adam
--
Now officially an EAR violation...
Have *you* violated EAR today? --> http://www.dcs.ex.ac.uk/~aba/rsa/
print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`