1998-03-24 - Chaffing and Winnowing

Header Data

From: Anonymous Sender <nobody@privacy.nb.ca>
To: cypherpunks@toad.com
Message Hash: fbc2b1b3310473177711f57f729e4b33584f025ac94924e30771e33998e3b798
Message ID: <b140a672fbd87f72ae59bcaf81a6c8ae@privacy.nb.ca>
Reply To: N/A
UTC Datetime: 1998-03-24 22:00:17 UTC
Raw Date: Tue, 24 Mar 1998 14:00:17 -0800 (PST)

Raw message

From: Anonymous Sender <nobody@privacy.nb.ca>
Date: Tue, 24 Mar 1998 14:00:17 -0800 (PST)
To: cypherpunks@toad.com
Subject: Chaffing and Winnowing
Message-ID: <b140a672fbd87f72ae59bcaf81a6c8ae@privacy.nb.ca>
MIME-Version: 1.0
Content-Type: text/plain


Aside from the considerable overhead created by C/W,
I observe a possible pitfall. suppose I start every
new message at ID# 0. The first time I C/W a message
everything works fine. The next time I C/W a message
with the same MAC, I give some very juciy clues to
what both messages were. This is because the item that
the MAC applied to was an ID number and a bit. well, that
bit is either zero or one... so any bit that corresponds
between my first and second message will yield an identicle
MAC, thus making it easy for anybody to seperate some of 
the wheat from the chaff, merely by simple observation.
though in a real implementation, I probably wouldn't be so
niave as to start every new message with the same packet
ID, I point out that there's an upper limit on the amount of
data that should be transmitted before a new
authentication key should be arranged... that is assuming that
the ID field was of finite size. Rivest mentioned in passing
using a 32 bit ID. That's an impressive number of bits to
C/W, but certainly not unattainable.

-SM2k






Thread