Frank Andrew Stevenson writes:
> Bob generates public key:
> 1) choose secret passphrase
> 2) Calculate MD5( passphrase ) and pads it repeadedly to get the number
> of bits in p less one.
> 3) calculates B = g ** md5md5... mod p , and publishes this as public key
Two things here: first, there is no need to pad the hash to be quite as
big as this. The discrete log problem can be attacked in two ways, one
based on the size of the exponent and one based on the size of the
modulus p. You can make the exponent considerably smaller than the
modulus. The work factor is proportional to half the exponent length,
so an exponent of 200-300 bits will require work of 2^100 to 2^150 to
break.
Second, this scheme relies completely on Bob's choice of a good
passphrase. It is questionable whether people will choose passphrases
with enough security to balance the rest of the system using typical
parameters today, i.e. ~100 bits of security.
If you are working in a mobile application where Bob can't carry a key
with him, you are stuck with this and just have to try to teach people
to choose good passphrases. However if there is any possibility of Bob
storing his key somewhere, that would usually be a preferred solution.
> Alice sends message to Bob:
> 1) Calculates MD5( message ) and pads to p-1 bits.
> 2) Calculates k = B ** md5md5... mod p
> 3) encrypts: ( g ** md5md5... mod p (Mk) , RC4( message , k ) )
> 4) sends message to Bob
One problem with doing it this way is that it allows an attacker to verify
a guess at the message. Particularly if messages are short this might be
a vulnerability in some contexts. As written it will also reveal whether
two messages are the same, although if you use salt it should fix that.
If you have any source of randomness at all, it would help to hash it in
with the message in generating k. Almost any hardware device will have
some kind of random source. Every little bit helps.
