[2372] in cryptography@c2.net mail archive
Yet another angle on Rivest's chaffing and export control
daemon@ATHENA.MIT.EDU (Dukhovni, Viktor)
Wed Mar 25 18:45:03 1998
From: "Dukhovni, Viktor" <Viktor-Dukhovni@deshaw.com>
To: "'cryptography@c2.net'" <cryptography@c2.net>
Date: Wed, 25 Mar 1998 17:00:55 -0500
No one seems to have pointed out the obvious and trivial consequence
of the clear separation of the algorithm into two layered components neither
of which appears to fall under export control regs:
The encryption can be implemented using an OS pipe connecting two
programs both of which can be exported:
wheat -k key -blockbits 1 messagefile | chaff -blockbits 1 >
messagefile.enc
The decryption is just:
winnow -k key -blockbits 1 messagefile.enc > messagefile
None of wheat (which is an ordinary HMAC generator), chaff which
just inserts a noise block into the file randomly before or after each
block, or winnow (which checks the HMAC on each block discarding the noise)
are separately controlled. Trying to export control shell pipes (!) is not
likely to get the BXA any joy.
If export controls are imposed on 1 bit block HMAC, one can always
expand each bit to an ASCII byte ('0' or '0xff') or larger block size as
necessary:
bitexpand -8 message | wheat -k key -blockbits 8 | chaff -blockbits
8
winnow -k key -blockbits 8 messagefile.enc | bitshrink -8 >
messagefile
The most suspect (from an export control view point) code is oddly
enough the chaff generator, since its random number generator needs to be
cryptographically strong in mixing the wheat with the chaff. There is no
obvious innocuous application for the chaffing code, even though alone it
does not constitute cryptography.
--
Viktor.