Chaffing and winnowing

I have just been notified that chaffing and winnowing does, indeed,
violate the export regulations. You can read them for yourself at
http://www.bxa.doc.gov/Encryption/encreg.htm, but here are a few parts


a. Designed or modified to use ``cryptography'' employing digital techniques
to ensure ``information security'';
b. Designed or modified to perform cryptanalytic functions;
c. Designed or modified to use ``cryptography'' employing analog techniques
to ensure ``information security'';
...
Note: 5A002 does not control the following:
b. Equipment containing ``fixed'' data compression or coding techniques;
...
g. Data authentication equipment that calculates a Message
Authentication Code (MAC) or similar result to ensure no alteration of
text has taken place, or to authenticate users, but does not allow for
encryption of data, text or other media other than that needed for the
authentication;

    So it seems 5A002.a  and 5A002.g cover such encryption technologies as
chaffing and winnowing. Interestingly enough, 5A002.b allows such functions
as the package transform (keyless coding), even though it uses encryption
algorithms.


- Mark Rosen
http://www.mach5.com/

>>>>> "Mark" == Mark Rosen <mrosen@peganet.com> writes:
    Mark> Note: 5A002 does not control the following: b. Equipment
    Mark> containing ``fixed'' data compression or coding techniques;
    Mark> ...  g. Data authentication equipment that calculates a
    Mark> Message Authentication Code (MAC) or similar result to
    Mark> ensure no alteration of text has taken place, or to
    Mark> authenticate users, but does not allow for encryption of
    Mark> data, text or other media other than that needed for the
    Mark> authentication;

But wasn't that the gist of Rivest's paper: he's not encrypting the
message, he's just obscuring it really, really well.

All this needs someone with the cash & the time to push it to court...

-- 
Stephen
---
all coders are created equal; that they are endowed with certain
unalienable rights, of these are beer, net connectivity, and the
pursuit of bugfixes...  - Gregory R Block

Stephen Zander <gibreel@pobox.com> wrote:
| 
| But wasn't that the gist of Rivest's paper: he's not encrypting the
| message, he's just obscuring it really, really well.

His point is that the message packets start out readable, and then by
adding other packets (not altering the originals) you gain security,
whether intentional or not - apparently encryption is performed by
accident and without a key.

So he argues that since this technique transforms a cleartext stream
to a secure one without use of any cryptographic technique or
algorithm, no act of encryption has happened.

However it is not that simple - for a start to gain real security you have
to be careful to mingle streams in very precise ways, to lose the
temporal statistics that give away the origins of each packet - you
have to match wheat to chaff on a packet by packet basis to get good
security.  Furthermore you have to use a CSRNG or true random source
to generate fake MACs, or have another MAC key for the complementary
stream(s) - It is not so easy to say that these precautions could be an
accidental act, or that they are entirely non-cryptographic.

However I view the process rather differently.  There are two channels
- the message is carried in the MAC and in the plaintext bits.
Chaffing simply serves to obliterate the plaintext channel.  The
recipient doesn't need to get the plaintext bits at all - they can
simply try the MAC against both 0 and 1, and choose the correct one.
(although this doubles the workload)

Furthermore an "attacker" can't tell, without breaking the MAC scheme,
whether the plaintext is genuine or a blind, and so this makes
chaffing/winnowing an ideal carrier of steganography.  It's like
sending a plaintext file and a ciphertext file together, with an
assertion that they correspond - unless you can prove this assertion
how can an outsider be convinced you are not hiding information in the
ciphertext file?  How can you prove this assertion without giving away
your MAC key?  How can you demonstrate you are using a MAC and not
simply triple-DES?


__Mark
[ markt@harlequin.co.uk | http://www.harlequin.co.uk/ | +44(0)1954 785433 ]

[Is this still appropriate for coderpunks?]

At 01:07 PM 5/14/98 +0100, Mark Tillotson wrote:
>However I view the process rather differently.  There are two channels
>- the message is carried in the MAC and in the plaintext bits.
>Chaffing simply serves to obliterate the plaintext channel.  The

But it _doesn't_ obliterate the plaintext channel;
it just obfuscates it a lot.

>recipient doesn't need to get the plaintext bits at all - they can
>simply try the MAC against both 0 and 1, and choose the correct one.
>(although this doubles the workload)

Depending on how sequence numbers are managed, it doesn't 
need to double it - if you try the MAC for 0, it either
succeeds or fails, and in either case you don't need to 
check the MAC for 1.  If you're using a shorter MAC which
might have collisions (e.g. 8 bits of a real MAC), you need to
check both, since both 0 and 1 could pass, trashing the bit,
and if you're using the "First different bit in MAC(0) and MAC(1)"
technique you obviously need to calculate both.

>Furthermore an "attacker" can't tell, without breaking the MAC scheme,
>whether the plaintext is genuine or a blind, and so this makes
>chaffing/winnowing an ideal carrier of steganography.  It's like
>sending a plaintext file and a ciphertext file together, with an
>assertion that they correspond - unless you can prove this assertion
>how can an outsider be convinced you are not hiding information in the
>ciphertext file?  How can you prove this assertion without giving away
>your MAC key?  How can you demonstrate you are using a MAC and not
>simply triple-DES?

It's easy to demonstrate that the wheat channel is using real MACs -
if you're hauled into court for some violation or lawsuit,
you can probably be ordered to deliver the key (if you kept it),
since it's "not" being used to keep the message secret,
"only" to authenticate it.  

For the chaffing techniques that can use random chaff, though, 
you really can't prove that the "random" numbers are random 
as opposed to stegotext without giving up the stegotext
unless they're generated by a pseudo-random algorithm
which uses a key you can reproduce (as opposed to a 
session key from /dev/random.)

Will the real use of chaffing/winnowing be to send
uninteresting cover traffic and carry stegotext as chaff?
				Thanks! 
					Bill
Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639