Subject: [Tsvwg] Bad cryptography suggestion in draft-larzon-udplite-04.txt

From: Mikael Olsson <[email-masked]>
Date: Thu, 28 Feb 2002 11:45:39 +0100

(I'm not on the tsvwg mailing list; I just caught an oddity in
draft-larzon-udplite-04.txt and thought I'd notify you of it.
Respond with me in the cc list if you want me to read your
response).

It is quite possible that this issue has already been raised
on the mailing list or elsewhere, but I really don't have 
the time to go looking for it, so I thought I'd just go ahead
and send this to the list. -Rather safe than sorry in these 
areas, right?

Quoted from draft-larzon-udplite-04.txt, on the section on 
encryption that does not spread damange across the entire
"non-sensitive" payload of a packet:
   "A class of such transforms would be transforms where the 
   sensitive part is encrypted using a strong transform as 
   usual, and the insensitive part is encrypted by XORing it 
   with a cryptographic hash computed over the cleartext of the 
   sensitive part.  However, it is clear that with the transforms 
   in use today, encryption eliminates the benefits that UDP
   Lite might bring."

From a security standpoint, this is an extraordinarily bad idea.
This is, in effect, a keystream cipher, with a potentially _very_
short keystream keyspace to boot, that may very well re-use the 
key stream twice if/when the "checksummed" portion of UDP Lite 
remains the same between two packets. 

In instances where only the UDP Lite header is checksummed (and
consequently encrypted with strong encrypion), this is exactly what 
will be happening, as one communication stream will always be using
the same ports, and getting the same checksum due to the UDP Lite
checksumming scheme.

As any cryptographer will tell you, re-using the same keystream
pretty much voids the cryptography:

- Let K be the keystream that results from hashing the sensitive part
  of a packet. Assume that the sensitive part of packets A and B
  is the same. This results in K becoming the same for both packets.
- Let A be the "non-sensitive" plaintext from the first packet
- Let B be the "non-sensitive" plaintext from the second packet

The cryptotext of A becomes: A xor K
The cryptotext of B becomes: B xor K

Now, if we take both cryptotexts and xor then with eachother,
we get:
  A xor K xor B xor K
simplified as
  A xor B xor (K xor K)
which, of course, becomes
  A xor B

This is _VERY_ sensitive to statistical analysis. Please reference 
the mistake that microsoft did with their SAM password encryption, 
where they used the same keystrem to encrypt both the NT hash
and the LM hash of the password and instantly made it crackable
with only a slight processing power increase over existing
password crackers.

There are also other potential problems as one can typically expect 
that the "sensitive" area of UDP Lite is much shorter than the
"non-sensitive" area. This would necessitate quite a bit of 
keystream stretching, with degradation of the keystream strength
as a result. Also, if only the UDP header is used as keystream
entropy, you get a maximum keyspace size of 32 bits (source port
and destination port -- the length and checksum are already known /
may be deduced), which can probably be reduced even further by making 
assumptions about the port spans.

I realize that the passage I'm referencing in the draft is only
a suggestion, but it is my belief that even suggestions of
using bad cryptography should be addressed as potientially
dangerous. Given the space allotted to cryptography considerations
in the current draft, I feel that suggested uses of cryptography
are better left out entirely and addressed separately, to allow
for more detailed analysis or perhaps even inclusion in work
being done by other ietf working groups.

However, there is, of course, no harm done in noting the problems
that the cryptography practices of today may cause for the 
indended operation of UDP Lite.

Regards,
Mikael Olsson

-- 
Mikael Olsson, Clavister AB
Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden
Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
Fax: +46 (0)660 122 50       WWW: http://www.clavister.com

"Senex semper diu dormit"

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg