[rc5] Suggestion for protocol

Fedor Kouranov ted99 at ibm.net
Tue Jun 24 12:10:55 EDT 1997


OK, what one needs for a spoofing attack is:

    Tools: tcpdump, knowledge in general and network programming, a genuine
client (no source!). Yeah, a multitasking computer.
    Hard parts: analysis of protocol.
    Result: the system will spoof keys at a preset rate, probably emulating
a proxy. It will test and correctly report all (or most) 'surprise' or 'F'
keys.

I have second thoughts about publishing the complete scheme I've just made
up. Well, it's trivial. If general public considers that it's safe, I can
send it in.

Now, concerning verification. I didn't quite understand the F keys proposed
by Seth. Does it mean that the client will store some plaintexts that
should be compared to the decrypted plaintext? This is fine, except for two
problems. The first is loss of 1 op/key per plaintext. The second is that
it's still rejectable because these plaintexts are fixed in the keyspace.

It seems that Seth didn't understand what I meant by checksum. OK, back to
pseudocode ;-) I didn't get a reply, so I believe that the clients decrypt
the first 32 bits. Now...

 ULONG ciphertext;
 ULONG plaintext;
 ULONG checksum = 0;
 ...
 for(offset = 0; offset < keyspacemask; offset++) {
   plaintext = RC5decode(ciphertext, startkey + offset); /*PSEUDOcode!!*/
   if plaintext == challtext
     blah();
   checksum += plaintext;
 }

The logged checksum is a *proof* that every key in the keyspace was
decrypted. There is *no* way to find the checksum for a given block except
for checking the complete block. So, let's imagine the worst: the keyspace
was exhausted and... no solution found! After rechecking the 10% that were
conquered by unauthenticated clients, no solution is found either! What do
we do?

Simple. Give away the authenticated blocks. Compare the report and the
checksum to the original one. If they do not differ, then the checking has
been performed.

What if someone decides to remove 'if plaintext == challtext' (save 1
op/key)? Well, as I mentioned before, there must be a solution in 16
blocks. If we check 32 reports of a particular host, we're very likely to
get a solution. If the host reported correct checksums and correct answers,
then the host is trusted.

The nice point about checksums is that they pose *no* load on servers at
all, except for storing/transferring them. I think that the use of
checksums *and* surprise solutions will guarantee us from spoofing.


 /** Christ Is Risen ! *** __+__ ******  Fedor "Ted" Kouranov  *****/
 /* Xristos Voskrese ! **   \|    ** ted99 at ibm.net * fedor at bu.edu **/
 /** Xristos Anesti ! ****   |\  ** http://enz.siobc.ras.ru/~fedor */

----
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.



More information about the rc5 mailing list