Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:16:20 ADT
Matt Blaze (mab@crypto.com)
Fri, 27 Mar 1998 05:42:29 -0500
"Dukhovni, Viktor" <Viktor-Dukhovni@deshaw.com> writes:
>
> 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.
> ...
Your pipe example suggests an even more interesting possibility than
this. As others (I think Ian Goldberg was the first) have pointed
out, with a small packet payload protected by a MAC, the payload
itself is superfluous - the receiving party can try all 2^{|message|}
possible messages until the correct one (that matches the MAC) is
found. So there's no reason to send overhead messages over the
channel. But, (as others have also pointed out), when you start
omitting the cleartext data, it gets hard to argue that what's going on
isn't cryptography and therefore exempt from export control.
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,
deleting the payload bits (or replacing them with some fixed
constant). The receiver, recognizing the missing payload, just
inserts all 2^{|message|} candidate packets before processing further.
Again, there's no reason this needs to be the same program that
verifies the MACs; an external program, inserted into the data stream
after on the receiver's side after receipt but ahead of the receiving
application, could do the expansion step just as well.
So you this suggests a pipe architecture like this:
The sender runs this pipeline:
alice$ generate_authenticated_pkts | delete_payload | send_over_network
While the receiver runs this:
bob$ receive_from_network | regenerate_possible_payloads | process_pkts
(Of course, for communications programs, this wouldn't always happen
with shell-level pipes, but rather by inserting processing into the
appropriate part of the protocol stack).
What's so interesting here? Observe that only delete_payload and
regenerate_possible_payloads need to know anything about winnowing or
chaffing (and don't need to know anything about MACs or secret keys).
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.
It is also worth noting that the regenerate_possible_payloads module
has a perfectly legitimate alternative function: it provides
transparent forward error correction, albeit only against errors in
the payload field.
I think that you could apply this technique to many existing protocols
today. In particular, consider IPSEC without confidentiality, which
should be exportable under the current rules, at least in binary form.
We could imagine that people who want network-layer confidentiality
but who can't get IPSEC with encryption could simply use the
exportable authentication-only version. Then they add a router
between them an the network (or add a layer to their protocol stack,
if their OS allows) that does the delete_payload and
regenerate_possible_payloads function. The only thing that has to
change in the authenticate-only TCP/IP implementation is the MTU,
which is generally a tunable parameter anyway.
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.
-matt
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:16:20 ADT