Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:17:18 ADT
Aaron D. Gifford (agifford@infowest.com)
Fri, 08 May 1998 18:53:10 +0000
Regarding Mark Rosen's code:
Michael J. Graffam (mgraffam@mhv.net) already mentioned the problems that can
be created by leaving out the serial no. for the packet. He also described a
possible solution, but I am NOT convinced that the solution is secure.
First, a couple of questions:
* Are there any drawbacks using a plain hash like SHA1 for packet
authentication as opposed to something like HMAC-SHA1?
* It appears that in your implementation, you generate 20 bogus ("chaff")
packets for each real ("wheat") packet, and that each packet contains a byte
of data. The wheat packet is inserted into the 20 packet stream at a random
location. The chaff packets data byte portion contains a random byte that may
or may not be the same as the wheat packet payload. Given all this, unless
the wheat data stream is unpredictable, aren't you losing information? As I
understood the chaffing process, a truly secure chaffing of a data stream
should include all possible combinations?
Regarding the expansion of data:
>From Mark's code, it appears that a wheat or chaff packet will be 21 bytes in
length. For each wheat packet, Mark generates 20 chaff packets. This is 21
packets multiplied by 21 bytes in length, or 441 bytes for every data byte, a
441-fold expansion.
If instead Mark stuck with the original 1 bit system Rivest outlines, INCLUDED
a 4 byte serial number and used a 20 byte hash/MAC, Mark would have 1 data bit
(and suppose he padded it to 1 byte in length) + 4 bytes for the serial + 20
bytes for the hash/MAC for a total of 25 bytes per packet. Mark would
generate only a single chaff packet for each wheat packet, the chaff data
value being the inverse of the wheat value, and order the packets in ascending
or descending order so that the order wouldn't disclose any information. A
single payload byte would then require only 8 wheat packets and 8 chaff
packets, for a total of 16 packets. Multiplied by 25 bytes length, Mark
generate only 400 bytes for each data byte, resulting in a more efficient
400-fold increase versus the 441-fold increase in his existing code. If he
packed the packets (omitting the 7 bits of padding in each packet), over the
16 packets (8 wheat, 8 chaff) that would squeeze out 14 more bytes, resulting
in only a 386-fold increase.
By using the original system Rivest describes, Mark would also have the
advantage of a serial number, which in my opinion is vital to be truly
secure. And because for every wheat packet, the maximum number of possible
chaff packets of differing value are also generated, the implementation would
have the full security of the chaffing/winnowing system (for a 1-bit packet
data load, only 2 possible values exist).
Mark's existing code only generates 20 possible chaff values for each wheat
value, and since the wheat value is a byte in length, there are 256 possible
values. I would think that this would significantly reduces the security of
the system. Unless the payload data is already cryptographically
unpredictable, I would think that any system NOT generating the full range of
possible chaff values for the data packet payload size would leak
information. Am I misled in my thinking here?
Aaron out.
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:17:18 ADT