Here is my second rant, this one about another highly desirable
privacy feature: stego support built-in to PGP.
It would be useful to build into PGP support for messages which can be
plausibily claimed are random numbers.
There are lots of reasons a PGP message is not a random number. The
obvious reasons are that it says "-----BEGIN blah" at the top, but
readers familiar with the packet formats will also know that even with
out that boiler plate there are constants in the text which inform the
recipient's PGP what type of message it is, how long the message is,
etc.
Someone with a nym of "Henry Hastur" wrote an application called
"stealth", it is utility which removes all this boiler-plate from PGP
2.x messages.
However there is another less obvious problem with PGP messages, they
have bias in signature and public key encrypted packets in the crypto
values.
For an RSA encrypted key packet the encrypted value is less than N,
the recipients RSA modulus by definition. That is the RSA encrypted
session key will be in the range 0..N-1. That's not uniform. An
opponent seeing lots of otherwise "stealthed" messages would be able
to accumulate this leaked information and reduce the plausible
deniability of the covert correspondents.
Similar biases will be leaked by El Gamal (note terminology "PGP uses
DH" people) in that components will be less than the public prime
modulus.
Stealth 2.x fixes this problem for RSA encrypted messages with a
stealth normalisation transform designed by Hal Finney.
Stealth 2.x is at:
http://www.dcs.ex.ac.uk/~aba/stealth/
The algorithm is described on Hal's pages at:
http://www.rain.org/~hal/ I think.
The implementation of the algorithm is described in the source code
distribution for stealth2.
There are some restrictions with stealthing PGP packets. It seems
like a waste of time to try to code the stealth transformations for
keyring packets, trust packets, signature packets, etc. Anything like
that belongs inside the encryption envelope, otherwise you haven't got
plausible deniability anyway, as stealth transformations are
reversible by third parties, you don't want any plaintext sticking
out.
So if we restrict ourselves to encrypted packets, the remaining
problem is multiple crypto-recipients.
One ugly inefficient suggestion is that the largest public key block
is going to be 1024 bytes (right? 4096 bit El Gamal encrypted key
packet). So you could code each stealthed public key encrypted packet
as 1k (+stealth transform expansion), and when you are trying to
decrypt, you try the first x blocks where x is the maximum number of
multiple recipients you think you are likely to see.
Then, once you've found a block encrypted to you, you try decrypting
at 1024 byte boundaries until you find the begining of the symmetric
cipher encrypted block.
(Once you've done that there will be an internal length count inside
that encrypted block, so you could then figure out if there are other
pgp packets after this block, and process them).
The other simpler option is just not to cope with multiple
crypto-recipients for stealthed messages.
Once you've got that lot built in to PGP, you have all you need to
build steganography applications. And you can always fall back to
mailing what are ostensibly hex encoded random numbers if the GAKkers
succeed in legislating mandatory GAK in your country.
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`