[RC5] Solutions for a faster DES-II-3
trif at serv.net
Sat Aug 1 15:21:11 EDT 1998
On Fri, 31 Jul 1998 gindrup at okway.okstate.edu wrote:
> I like the idea of prefetching the blocks. However, individual
> fetches of the ciphertext are going to have the same problem that
> fetching blocks has.
Not quite as badly. There is less overhead in transmitting just the
IV (initialization vector) and ciphertext than there is in downloading
a thousand blocks. Also, if people who are running really huge farms
are using pproxies, the pproxy only needs to ask once to inform the
entire farm. But still, everybody asking simultaneously would be bad,
so we need to have some method for the clients to be assigned an offset
from time zero to ask. Another annoying problem is that RSA has not
been terribly on the ball with releasing the info on time.
> Instead, have the proxy network multicast the ciphertext to all IP
> addresses that requested prefetch blocks.
Doesn't work with firewalls, doesn't work with dynamic IP dialup clients,
> Clients that do not receive the ciphertext block should perform
> *forward* encryptions of the known plaintext with the blocks they
> have and return those to a special proxy/server that will compare
> the returned blocks with the known ciphertext *and* send the
> ciphertext to the reporting client.
Unfortunately, this scheme (and the one to make a massive look up table
of all the ciphertexts produced from a known plaintext), are made useless
by the use of the initialization vector. The purpose of the
initialization vector is to make just such an attack useless by changing
the plaintext before the encryption. We have to know the IV before
clients can start cracking.
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5