[NTLUG:Discuss] OT: Cryptography Key Length

[John K. Taber]

On Sat, 2007-05-26 at 16:28 -0500, Dennis Rice wrote:
> Just wanting to start a general topic discussion regarding encrypting of 
> a message.  I am assuming that all have some familiarity with GPG (alias 
> PGP) in the open source world.
> 
> The old legal limits to encryption using a symmetric key was 56 bits, 
> and is now 128 if I understand correctly.  Today, I am under the 
> impression that an asymmetric key is equivalent to a shorter symmetric key.
> 
> In presenting the GPG process in class the other day, I observed that 
> the new limits to GPG for key length was between 1024 and 4096 bits (it 
> use to be 768 to a "recommended" 2048, default 1024).  I attempted to 
> create a 8192 bit key, and the gnupg software said no (nicely), so I 
> chose a 4096 key length.
> 
> OK, all that is great, but how does that fit into the limitations 
> presented by the law?  There are distinct reasons for limiting the key 
> length by the government (no opinion presented), and I thought it was 
> 128 bits.  So how does one have the right to create a 4096 bit key and 
> not have the feds coming down on us?  I sure would hate to see a 
> limitation to encryption placed on us by limiting the encryption key, 
> but at the same time, I more dislike the idea of some drug dealer or 
> terrorist sending encrypted messages back and forth using a large key 
> under gpg.
> 
> Hopefully a general discussion that might be of interest to more than 
> just myself.  Appreciate your discussion.

You are asking a big question. It has been years since I was involved
with cryptography, and I am very much out of date. With that caveat out
of the way, let me try to answer you.

The legal basis for controlling cryptography (and cryptanalysis) is IMO
peculiar. It is the Arms Export and Import Act, in the United States
Code (USC), I forget the Title. The idea behind the Act is the control
of military exports (imports too) to further our foreign policy. It is
not specifically directed at cryptography, but at enabling foreign
policy. It does not forbid export, but requires a license for the
export. Basically, if DoD and the State Dept think the nation of
Frulania is a good guy, the Govt will license the export of a particular
cryptographic system or fighter plane to it. If they don't think
Frulania is a good guy, it won't get it, at least not legally.

The implementation of the Act is deferred to the Executive (DoD and
State, in other words) which makes up and publishes a list of military
equipment whose export must be licensed. Naturally, a request for a
license may be denied. This list is the Munitions List, part of the
International Traffic in Arms Regulations (ITAR) in the Codified Federal
Regulations (CFR).

Before the 80s it wasn't clear that cryptographic software was included.
Cryptographic equipment was, for sure, but an argument could have been
made that software isn't equipment within the meaning of the law. The
deficiency in the ITAR was noted, and cryptographic software was
specifically included in auxiliary military equipment as I recall. 

In short, to export cryptography to friendly country or unfriendly you
need an arms export license. 

There is no legal basis for proscribing or prescribing key lengths. That
is a common misunderstanding in the technical world. However, EXPORTING
strong encryption, which may be nothing more than a huge keylength, may
be another matter, and may fall under ITAR. 

The commercial need for encryption is so great and so obvious that
eventually the government relaxed some of its earlier restrictions on
"export" of cryptographic systems and keylengths. For certain uses, and
certain keylengths no licensing is now required. For example, PINs on
banking transactions. There was a lot of negotiating back and forth on
this, and I am admittedly not up to date.

For more information you should ask on the Usenet newsgroup sci.crypt. I
think you will get better advice there, at least on the technical
issues. For the legal issues, though, please see your lawyer.

John