[2385] in cryptography@c2.net mail archive
Re: Yet another angle on Rivest's chaffing and export control
daemon@ATHENA.MIT.EDU (Bill Stewart)
Fri Mar 27 16:39:30 1998
Date: Fri, 27 Mar 1998 11:14:34 -0800
To: Matt Blaze <mab@crypto.com>
From: Bill Stewart <bill.stewart@pobox.com>
Cc: cryptography@c2.net, coderpunks@toad.com
In-Reply-To: <199803271042.FAA09068@tpc.crypto.com>
At 05:42 AM 3/27/98 -0500, Matt Blaze wrote:
>> wheat -k key -blockbits 1 messagefile | chaff -blockbits 1 >
>>messagefile.enc
>with a small packet payload protected by a MAC, the payload
>itself is superfluous - the receiving party can try all 2^{|message|}
>But there's no reason that the application that generates the MAC has
>to be the one that omits the payload. An external program inserted
>into the output stream on the sender's side could do just as well,
You still end up with "components of a cryptosystem"
contamination of your system that way, though less so if
removing the payload is done by somebody other than the sender.
On the other hand, you can build a pipeline that looks like
message ----------->wheat----->mix-->[somebody else's mixer]-->
\ /
invert--->wheat---/
>The programs generate_authenticated_pkts, send_over_network,
>receive_from_network, and process_pkts are just the normal application
>programs that a user would get from Microsoft, perhaps even ones that
>already exist today. The only requirement is that the
>generate_authenticated_pkts application would have to be constrained
>to generate small enough payloads to allow the
>regenerate_possible_payloads program to easily generate the
>exponentially many candidate packets.
Realistically, you probably don't want more than 1 byte payloads,
which takes 256 MACs per byte. In general, an n-bit payload
takes 2**n MACs, averaging half that, vs 2*n**1 for n 1-bit payloads.
Using it for a 64-byte packet would be infeasible, much less
for a 576-byte or 1536-byte MTU. TCP/IP header compression can let you
get down to ~ 3 bytes of header per packet, so you could conceivably
run an IPSEC-authenticated telnet session with 4-byte payloads
(1 typed character plus header), but that takes 4 billion MACs per keystroke,
which would be a mite slow; you'd be far better off creating a large
number of these sessions and using the MAC key to carry the data
while sending cover traffic in the wheat/chaff.
>I wonder if anyone is shipping an exportable IPSEC-authenticate implementation
>today. If so, building a delete_payload/regenerate_possible_payloads
>router would be a very interesting exercise, and might even be a
>practical way to bypass export controls.
Thanks!
Bill
Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
