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
participants (4)
-
bill.stewart＠pobox.com -
Mark Rosen -
Mark Tillotson -
Stephen Zander