From: Scott Brickner <sjb@universe.digex.net>
Date: Wed, 6 Dec 95 14:28:05 PST
To: cypherpunks@toad.com
Subject: Re: Solution for US/Foreign Software?
In-Reply-To: <aceb2a8d1b021004e6f8@[205.199.118.202]>
Message-ID: <199512062229.RAA16714@universe.digex.net>
MIME-Version: 1.0
Content-Type: text/plain


Timothy C. May writes:
>Yes, I read your proposal. The "hooks" term is not my coinage, but refers
>to this general idea. I urge you to read what others, including companies,
>have had to say on this matter. Much of the debate on "interoperability"
>revolves around details of entry points to crypto modules and such hooks.
>
>No point in arguing with Jim on this anymore, so I won't.

I agree.  It does bring to mind an idea, though.  Netscape builds an
exportable system by choosing a random 128 bit number and then just
including 88 bits of it in plaintext.

This means one of two things.  Either there's a field which holds the
"key", but the export version stores 88 bits plain + 40 bits cipher,
and knows this structure, or there's a field which holds the 128 bit
enciphered key, and a second field which holds the 88 bits of plaintext
key.

In the latter case, a patch which modifies the code which stores the
88 bit plaintext field to write all zeros would be almost trivial.
Just over-write the store instructions with noops, most likely.

In the former, the patch would be more significant, but still possible.
You'd disable the "write the plain" part and extend the "decode the
cipher" part to decode all 128 bits --- probably just a loop test.

Either patch for a given system should require less than a page of
explanation.

I wonder how the ITAR would view this.