// COMPLETE THREAD

Re: Solution for US/Foreign Software?

2 expanded posts ยท every known parent and child

NODE a7194d96Re: Solution for US/Foreign Software?
At 6:21 PM 12/6/95, jim bell wrote:

>NO!  You didn't read my commentary carefully enough.   These "hooks" (your
>words) will, in effect, already be connected to encryption software weak
>enough to make NSA happy.  You know, 40 bit keys or something like that.
>But instead of being in one large file, embedded into a program, it'll be
>TWO files.  Simple programming change.  Everything that
>implements/defines/limits the encryption to 40 bits will be in the smaller
>file.
>This really isn't a "hook," it's an internal connection between two
>portions of the same program. (actually, it wouldn't need to be in two
>separate files; a file which implements a patch for the first file would
>work great.)
>
>It'll be exportable, because its key size is "acceptable."  At the time
>the export license is requested, the replacement module to increase key
>size probably won't even  exist, in order to avoid giving the USG an
>excuse to deny the export license.   After the license is obtained, the
>replacement module is written and shipped to domestic users.
>
>I fully realize the USG won't "like" this kind of thing.  But if they are
>trying to take the position that certain kinds of encryption software CAN
>be exported, and some can't, they're going to have to approve SOME
>programs for export, using criteria which at least pretend to be
>objective.

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.

Good luck, Jim, in introducing such a product.

--Tim May

Views here are not the views of my Internet Service Provider or Government.
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
tcmay@got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
Corralitos, CA              | knowledge, reputations, information markets,
Higher Power: 2^756839      | black markets, collapse of governments.
"National borders are just speed bumps on the information superhighway."
NODE d8e2bdfcRe: Solution for US/Foreign Software?
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.