Encryption Exports: Small Step Forward, Big Step Back

Kathleen Ellis, editor of the Privacy News Portal, attended yesterday's press briefing about a proposed loosening of export restrictions, and wrote the following feature article about the current situation. Click below for more.

Actually, let me hit you with a few links before you get started:

• EPIC's page on the proposed Cyberspace Electronic Security Act
• Proposed text of the bill
• White House analysis of the bill - really an executive summary
• Wired coverage, by Declan McCullagh
• Update: Press statements, including briefing transcript

Encryption Exports: Small Step Forward, Big Step Back
by Kathleen Ellis
September 17, 1999

Prominent U.S. Government representatives yesterday announced at a White House press briefing that the President was proposing legislation on encryption policy, and that the Department of Commerce was revising its export restrictions on some encryption products. Last year, Vice President Al Gore vowed to further loosen restrictions and propose a solution to the encryption issue, which has been the subject of contentious debate for the past decade.

The legislation, known as the Cyberspace Electronic Security Act of 1999 (CESA), has been transmitted to Congress by President Clinton. The bill purports to strike a "compromise" between the needs of law enforcement for access to data and the needs of Internet users to secure and their e-mail, web transactions, and stored data from hackers or thieves. According to the text of the bill, "society's increasing reliance on information systems in this new environment exposes U.S. citizens, institutions, and their information to unprecedented risks." Despite this acknowledgement, the bill clearly gives consideration to the needs of law enforcement and intelligence agencies first; "The failure to provide law enforcement with the necessary ability to obtain the plaintext version of the evidence makes existing authorities useless."

One of the major provisions of CESA is to allocate $80 million dollars for an FBI "Technical Support Center", which would provide assistance to federal, state, and local law enforcement officials. The bill also reinforces the confidentiality of law enforcement intelligence techniques used to gather information about suspected criminals. "The Department of Justice has developed this legislation with the assistance of agencies in government," said Attorney General Janet Reno. "Law enforcement has tools at its disposal to fight crime, but those tools are rendered useless when encryption gets involved". Reno said that CESA "balances the needs of privacy and public safety".

Perhaps most the most noteworthy provision of the bill is the resurrection of key escrow, a solution long considered insufficient, insecure and obsolete by experts. Key escrow is a technology that entails entrusting one's private keys with a trusted third party, so that theoretically, a law enforcement official would be able to present that third party with a warrant in order to gain access to the plaintext of the encrypted data. Although the bill does not require domestic users to utilize an escrowed cryptosystem, the bill provides a legal framework to protect users from disclosure of their decryption keys by their trusted third party without a court order. The bill also proposes to implement strict guidelines outlining the circumstances under which a law enforcement agent may be granted access to a decryption key held by the third party.

This mention of key escrow worries privacy activists, who have heard the use of such language by the administration before. "This raises the specter of collusion between law enforcement and industry to build back door access into encryption products," says David Sobel, General Counsel for the Electronic Privacy Information Center. According to EPIC's statement, the bill will eventually "provide a legal framework for access to decryption keys," a prospect which worries many activists and internet users alike.

Sobel would rather see the Security and Freedom through Encryption Act determine the U.S. Government's encryption policy. Authored by congressman Bob Goodlatte, SAFE would essentially force the government to reverse its stance on the encryption issue. Unfortunately, passage of the SAFE Act now seems unlikely, in light of Deputy Secretary of Defense John Hamre's remark during the briefing that if the SAFE Act passes the House and Senate, "the Department of Defense will ask the President to veto it".

Also announced at the press conference were revisions to the Department of Commerce's encryption export policy. According to a report released at the briefing, the export requirements will be revised to allow software exports of products of any key length, after the product is first submitted for review by the Commerce Department, and as long as the manufacturer of the product meets strict guidelines for post-export reporting of any user or distributor who obtains the software directly from the licensee. Secretary of Commerce William Daley announced that that the Bureau of Export Administration would streamline the revision and reporting process, but was unclear about specific changes to the current procedure.

Two prominent industry groups are very enthusiastic about this proposal. "Today's decision articulates a policy that is good for America, good for our nation's high-tech industry, and good for the tens of millions of Americans who use computers and want them to be secure" says a press release from Americans for Computer Privacy, a group that has lobbied for legislative reform and is funded primarily by technology companies. In a statement published by the Computer Systems Policy Project, Sun Microsystems President and CEO Scott McNealy (who made headlines on Slashdot for his remarks telling reporters that the privacy issue was a "red herring" and that "you have zero privacy anyway...get over it") said "we applaud the Administration's recognition that the universal use of strong encryption will promote the benefits of a networked world while protecting Americans' privacy, safety and security,". CSPP is comprised of eleven CEOs from major Information Technology companies, such as IBM, Dell, and Intel.

James Steinberg, Deputy Assistant for National Security Affairs, opened the briefing by praising both groups for thier assistance in authoring the proposal, so it's no surprise that they're eager to ingratiate themselves to the Clinton Administration, while at the same time self-importantly emphasizing their effectiveness by declaring a victory. EPIC's David Sobel says "it appears that the FBI and large computer companies have reached an agreement on encryption, but that is not necessarily in the interest of the average computer user." Any compromise reached by these two groups could result in "less security than advertised, with hidden vulnerabilities the government can exploit".

Secretary Daley was repeatedly asked during the briefing what purpose the one-time review served, and under what circumstances an export license exception would be granted or denied; no clear answer was given. The U.S. Government may wish to allow exports only of flawed or escrowed encryption products using encryption above a certain key length, but have given up on explicitly pursuing that as a goal. Large software companies, the kind represented by ACP and CSPP, have lost a lot of business because of the export restrictions, and with each year that passes they may become less likely to object to making a few changes to their crypto modules in order to finally gain access to the foreign market.

In some ways, this proposal is good for the companies who have existed for so long without the ability to export their stronger security products at all until now, but for the rest of us, the proposal is neutral at best and abysmal at worst. As larger, wealthier proponents of crypto liberalization get what they want and contentedly back out of the debate on this issue (as American banks did when they were granted license exception to export security software to their overseas offices), further positive alterations to export policy start to seem less and less likely to happen. This is bad for American cryptographers who wish to discuss their work with their colleagues on the Internet. It's even worse for users, who may end up using insecure products without knowing it.

It's unclear what will happen at this point. The current congressional climate suggests that CESA will not pass without a significant push from the Clinton Administration. Even if the bill is defeated, however, Internet users around the world should continue to be cautious about purchasing commercial encryption products that originate inside the U.S.; you never know what may be lurking within.

Comments

Here's a Denial of Service attack.

[Anonymous Coward]

/*
This export control stuff can't be anything to do with stopping crooks. It's more like allowing crooks to harm law abiding US citizens one way or another.

Don't worry about us "foreigners" we can get crypto code.

And what follows an example of how a foreigner can indirectly bring down a US server, without breaking any local laws. This could be easily done on USENET as well, anyone know what would happen? Shutdown of US USENET servers?

*/

/*
* pgpIDEA.c - C source code for IDEA block cipher.
* Algorithm developed by Xuejia Lai and James L. Massey, of ETH Zurich.
*
* $Id: pgpIDEA.c,v 1.16 1997/10/14 01:48:18 heller Exp $
*
* There are two adjustments that can be made to this code to speed it
* up. Defaults may be used for PCs. Only the -DIDEA32 pays off
* significantly if selectively set or not set. Experiment to see what
* works best for your machine.
*
* Multiplication: default is inline, -DAVOID_JUMPS uses a different
* version that does not do any conditional jumps (a few percent
* worse on a SPARC, better on other machines), while
* -DSMALL_CACHE takes it out of line to stay within a small
* on-chip code cache. (Not really applicable with current L1
* cache sizes.)
* Variables: normally, 16-bit variables are used, but some machines do
* not have 16-bit registers, so they do a great deal of masking.
* -DUSE_IDEA32 uses "int" register variables and masks explicitly
* only where necessary. On a SPARC, for example, this boosts
* performance by 30%.
*
* The IDEA(tm) block cipher is covered by a patent held by ETH and a
* Swiss company called Ascom-Tech AG. The Swiss patent number is
* PCT/CH91/00117. International patents are pending. IDEA(tm) is a
* trademark of Ascom-Tech AG. There is no license fee required for
* noncommercial use. Commercial users may obtain licensing details from
* Dieter Profos, Ascom Tech AG, Solothurn Lab, Postfach 151, 4502
* Solothurn, Switzerland, Tel +41 65 242885, Fax +41 65 235761.
*
* The IDEA block cipher uses a 64-bit block size, and a 128-bit key
* size. It breaks the 64-bit cipher block into four 16-bit words
* because all of the primitive inner operations are done with 16-bit
* arithmetic. It likewise breaks the 128-bit cipher key into eight
* 16-bit words.
*
* For further information on the IDEA cipher, see these papers:
* 1) Xuejia Lai, "Detailed Description and a Software Implementation of
* the IPES Cipher", Institute for Signal and Information
* Processing, ETH-Zentrum, Zurich, Switzerland, 1991
* 2) Xuejia Lai, James L. Massey, Sean Murphy, "Markov Ciphers and
* Differential Cryptanalysis", Advances in Cryptology - EUROCRYPT'91
*
* This code runs on arrays of bytes by taking pairs in big-endian order
* to make the 16-bit words that IDEA uses internally. This produces the
* same result regardless of the byte order of the native CPU.
*/

#include "pgpSDKBuildFlags.h"

#ifndef PGP_IDEA
#error you must define PGP_IDEA one way or the other
#endif

#if PGP_IDEA /* [ */

#include
#include "pgpConfig.h"

#include "pgpSymmetricCipherPriv.h"
#include "pgpIDEA.h"
#include "pgpMem.h"
#include "pgpUsuals.h"

/* If IDEA32 isn't predefined as 1 or 0, make a guess. */
#ifndef USE_IDEA32
#if UINT_MAX > 0xffff
#define USE_IDEA32 1
#endif
#endif

#if USE_IDEA32 /* Use >16-bit temporaries */
#define low16(x) ((x) & 0xFFFF)
typedef unsigned int uint16; /* at LEAST 16 bits, maybe more */
#else
#define low16(x) (uint16)(x)
typedef PGPUInt16 uint16;
#endif

/* A few handy definitions */
#define IDEA_ROUNDS 8
#define IDEA_KEYLEN (6*IDEA_ROUNDS+4)
#define IDEA_KEYBYTES (sizeof(PGPUInt16) * IDEA_KEYLEN)


/*
* Flags in priv array to record whether key schedule is in encrypt
* or decrypt mode
*/
#define IDEA_ENCRYPTION_MODE 0x11
#define IDEA_DECRYPTION_MODE 0x22

/* Private functions */

/* Expand a 128-bit user key to a working encryption key EK */

static void
ideaExpandKey(PGPByte const *userkey, PGPUInt16 *EK)
{
int i, j;

for (j=0; j> 7;
EK += i & 8;
i &= 7;
}
} /* ideaExpandKey */

/*
* Compute the multiplicative inverse of x, modulo 65537, using Euclid's
* algorithm. It is unrolled twice to avoid swapping the registers each
* iteration, and some subtracts of t have been changed to adds.
*/
static uint16
mulInv(uint16 x)
{
uint16 t0, t1;
uint16 q, y;

if (x = 2, this fits into 16 bits */
y = 0x10001L % x;
if (y == 1)
return low16(1-t1);
t0 = 1;
do {
q = x / y;
x = x % y;
t0 += q * t1;
if (x == 1)
return t0;
q = y / x;
y = y % x;
t1 += q * t0;
} while (y != 1);
return low16(1-t1);
} /* mulInv */

/*
* Compute IDEA decryption key DK from an expanded IDEA encryption key EK
* Note that the input and output may be the same. Thus, the key is
* inverted into an internal buffer, and then copied to the output.
*/
static void
ideaInvertKey(PGPUInt16 const EK[IDEA_KEYLEN], PGPUInt16 DK[IDEA_KEYLEN])
{
int i;
uint16 t1, t2, t3;
PGPUInt16 temp[IDEA_KEYLEN];
PGPUInt16 *p = temp + IDEA_KEYLEN;

t1 = mulInv(*EK++);
t2 = -*EK++;
t3 = -*EK++;
*--p = mulInv(*EK++);
*--p = t3;
*--p = t2;
*--p = t1;

for (i = 0; i >16;
return (b - a) + (b >16, \
x = (x-t16) + (x>16), \
(x-t16)+(x>8);
outbuf[1] = (PGPByte)x1;
outbuf[2] = (PGPByte)(x3>>8);
outbuf[3] = (PGPByte)x3;
outbuf[4] = (PGPByte)(x2>>8);
outbuf[5] = (PGPByte)x2;
outbuf[6] = (PGPByte)(x4>>8);
outbuf[7] = (PGPByte)x4;
} /* ideaCipher */

/*
* Exported functions
*/

static void
ideaKey(void *priv, void const *key)
{
/* Do key schedule for encryption, can be converted later */
ideaExpandKey((const PGPByte *) key, (PGPUInt16 *)priv);
*((PGPByte *)priv + IDEA_KEYBYTES) = IDEA_ENCRYPTION_MODE;
}

static void
ideaEncrypt(void *priv, void const *in, void *out)
{
/* Make sure key schedule is in the right mode */
if (*((PGPByte *)priv + IDEA_KEYBYTES) != IDEA_ENCRYPTION_MODE) {
ideaInvertKey ((PGPUInt16 *)priv, (PGPUInt16 *)priv);
*((PGPByte *)priv + IDEA_KEYBYTES) = IDEA_ENCRYPTION_MODE;
}
/* Do the operation */
ideaCipher((const PGPByte *) in, (PGPByte *) out, (PGPUInt16 *)priv);
}

static void
ideaDecrypt(void *priv, void const *in, void *out)
{
/* Make sure key schedule is in the right mode */
if (*((PGPByte *)priv + IDEA_KEYBYTES) != IDEA_DECRYPTION_MODE) {
ideaInvertKey ((PGPUInt16 *)priv, (PGPUInt16 *)priv);
*((PGPByte *)priv + IDEA_KEYBYTES) = IDEA_DECRYPTION_MODE;
}
/* Do the operation */
ideaCipher((const PGPByte *) in, (PGPByte *) out, (PGPUInt16 *)priv);
}

/*
* Do one 64-bit step of a Tandem Davies-Meyer hash computation.
* The hash buffer is 32 bytes long and contains H (0..7), then G (8..15),
* then 16 bytes of scratch space. The buf is 8 bytes long.
* xkey is a temporary key schedule buffer.
* This and the extra data in the hash buffer are allocated by the
* caller to reduce the amount of buffer-wiping we have to do.
* (It's only called from ideaWash, so the interface can be a bit
* specialized.)
*/
static void
ideaStepTandemDM(PGPByte *hash, PGPByte const *buf, PGPUInt16 *xkey)
{
int i;

/* key1 = G >8);
hash[2*i+1] = (PGPByte)xkey[i];
}

/* Do the initial blocks of the hash */
i = len;
while (i >= 8) {
ideaStepTandemDM(hash, buf, xkey);
buf += 8;
i -= 8;
}
/*
* At the end, we do Damgard-Merkle strengthening, just like
* MD5 or SHA. Pad with 0x80 then 0 bytes to 6 mod 8, then
* add the length. We use a 16-bit length in bytes instead
* of a 64-bit length in bits, but that is cryptographically
* irrelevant.
*/
/* Do the first partial block - i 6) {
pgpClearMemory(hash+24+i, 8-i);
ideaStepTandemDM(hash, hash+24, xkey);
i = 0;
}
pgpClearMemory(hash+24+i, 6-i);
hash[30] = (PGPByte)(len >> 8);
hash[31] = (PGPByte)len;
ideaStepTandemDM(hash, hash+24, xkey);

/* Re-schedule the key */
ideaExpandKey(hash, xkey);

pgpClearMemory( hash, sizeof(hash));
}

/*
* Define a Cipher for the generic cipher. This is the only
* real exported thing -- everything else can be static, since everything
* is referenced through function pointers!
*/
PGPCipherVTBL const cipherIDEA = {
"IDEA",
kPGPCipherAlgorithm_IDEA,
8, /* Blocksize */
16, /* Keysize */
IDEA_KEYBYTES + 1, /* Last one remembers encrypt vs decrypt */
alignof(PGPUInt16),
ideaKey,
ideaEncrypt,
ideaDecrypt,
ideaWash
};

#if UNITTEST /* Currently unused; left in in case of future need */

/* Test driver proper starts here */
#include
#include
/*
* This is the number of Kbytes of test data to encrypt.
* It defaults to 1 MByte.
*/
#ifndef BLOCKS
#ifndef KBYTES
#define KBYTES 1024
#endif
#define BLOCKS (64*KBYTES)
#endif

int
main(void)
{ /* Test driver for IDEA cipher */
int i, j, k;
PGPByte userkey[16];
PGPByte priv[IDEA_KEYBYTES+1];
PGPByte XX[8], YY[8], ZZ[8];
clock_t start, end;
long l;

/* Make a sample user key for testing... */
for(i=0; i16; i++)
userkey[i] = i+1;

/* Compute encryption subkeys from user key... */
ideaKey(priv, userkey);
#if 0
ideaExpandKey(userkey, EK);
printf("\nEncryption key subblocks: ");
for (j=0; jIDEA_ROUNDS+1; j++) {
printf("\nround %d: ", j+1);
if (j IDEA_ROUNDS)
for(i=0; i6; i++)
printf(" %6u", EK[j*6+i]);
else
for(i=0; i4; i++)
printf(" %6u", EK[j*6+i]);
}

/* Compute decryption subkeys from encryption subkeys... */
ideaInvertKey(EK, DK);
printf("\nDecryption key subblocks: ");
for (j=0; jIDEA_ROUNDS+1; j++) {
printf("\nround %d: ", j+1);
if (j IDEA_ROUNDS)
for(i=0; i6; i++)
printf(" %6u", DK[j*6+i]);
else
for(i=0; i4; i++)
printf(" %6u", DK[j*6+i]);
}
#endif

/* Make a sample plaintext pattern for testing... */
for (k=0; k8; k++)
XX[k] = k;

printf("\n Encrypting %d bytes (%ld blocks)...", BLOCKS*16, BLOCKS);
fflush(stdout);
start = clock();
memcpy(YY, XX, 8);
for (l = 0; l BLOCKS; l++)
ideaEncrypt(priv, YY, YY); /* repeated encryption */
memcpy(ZZ, YY, 8);
for (l = 0; l BLOCKS; l++)
ideaDecrypt(priv, ZZ, ZZ); /* repeated decryption */
end = clock() - start;
l = end * 1000 / CLOCKS_PER_SEC + 1;
i = l/1000;
j = l%1000;
l = BLOCKS * 16 * CLOCKS_PER_SEC / end;
printf("%d.%03d seconds = %ld bytes per second\n", i, j, l);

printf("\nX %3u %3u %3u %3u %3u %3u %3u \n",
XX[0], XX[1], XX[2], XX[3], XX[4], XX[5], XX[6], XX[7]);
printf("\nY %3u %3u %3u %3u %3u %3u %3u \n",
YY[0], YY[1], YY[2], YY[3], YY[4], YY[5], YY[6], YY[7]);
printf("\nZ %3u %3u %3u %3u %3u %3u %3u \n",
ZZ[0], ZZ[1], ZZ[2], ZZ[3], ZZ[4], ZZ[5], ZZ[6], ZZ[7]);

/* Now decrypted ZZ should be same as original XX */
for (k=0; k8; k++)
if (XX[k] != ZZ[k]) {
printf("\n\07Error! Noninvertable encryption.\n");
exit(-1); /* error exit */
}
printf("\nNormal exit.\n");
return 0; /* normal exit */
} /* main */

#endif /* 0 */


#endif /* ] PGP_IDEA */


/*__Editor_settings____

Local Variables:
tab-width: 4
End:
vi: ts=4 sw=4
vim: si
_____________________*/

Re:Bill of Rights interpretation

[Analog]

Well, we'll have to disagree here. You see that as granting to law enforcement the right to access my private information. I see it as explicitly forbidding law enforcement that right, with exceptions to be made when law enforcement already has evidence that a crime has occured. Why else would a warrant require presenting said evidence to a judge in order to obtain it? Let's look at the rest of the amendment, shall we?

"and no warrants shall issue but upon probable cause, supported by oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized."

I realize that probable cause has been watered down to some ridiculous levels in this country, but I would also point out that attitudes like yours have allowed it to happen.

So what we have here is law enforcement (and you, apparently) telling us that I don't have the right to be secure in my belongings unless there is evidence that I have committed a crime, at which point law enforcement can try to obtain permission to access the things they believe were involved.

Instead, I only have the right to be as secure as they decide I need to be, and furthermore I need to give them a copy of the key to my front door so they can get in more easily, without my realizing they've done so, and fish around until they find something.

Does this really make sense to you? Perhaps a class in critical thinking can help.

As far as trying somewhere else, if you would like a police state to live in, there are plenty to choose from; somehow, though, I feel safe in assuming you won't be leaving anytime soon.

Re:WTF? Confidentiality of method of decryption?

[phil reed]

I mean, if I, as the prosecution, don't have to reveal to the court how I decrypted the "evidence", doesn't that give me just a wee bit too much power?

I wonder if that part would stand up to Supreme Court review?


...phil

Re:PGP is junk

[David Price]

According to the PGP DH vs. RSA FAQ, one of the primes used to generate DH keys is selected from a limited set, but the preselection does not severely impact security, and you're given the option to spend the time to generate your own prime.

Re:Dialog:

[David Price]

Exactly what I was thinking after I read this article. Encrypted information could be thought of as secret documents kept in a strongly locked box.

If law enforcement gains probable cause that I have illegal items, or evidence of illegal activity, in my lockbox, they can get a subpoena to force me to open the box. As you pointed out, if I refuse, I go to jail, and I can be kept in jail while the box is being forcibly opened.

Alternatively, with a search warrant the box can be seized as evidence and the law enforcement agency can break open the box without my cooperation. This breaking job would be a forensic activity, and I as the defendant, should the evidence within the box cause me to come to trial, have the right to question the officer who opened the box. The methods used to open the box are perfectly germane to discuss in court; many cases are sunk by reasonable doubt brought on by evidence mishandling.

The fact that my box is strongly or weakly locked should not matter, from a legal standpoint. It could be a massive, bank-quality safe, or an unlocked file cabinet; in either case, law enforcement must leave it alone unless they go through the proper channels to gain the right to sieze the evidence within the box. They certainly don't have the right to tell me how strongly I may lock my private documents - because, again, if it's beyond their capacity to open, they just get a judge to order me to, under penalty of prison.

Applying these principles to crypto, this means that a search warrant (or the equivalent, a wiretap approval from a judge) should be necessary to collect my information, either covertly or by direct siezure of the media on which the information lies. The two activities should be legally equivalent. Once the information has been legally siezed, the law enforcement agency may use its computational or cryptanalytical resources to crack my message, without needing another warrant to do so. (These attacks should only be allowed against data collected legally, of course.)

If it's beyond law enforcement's capacity to crack the crypto in question, or such a crack attack would take unreasonably long (hence denying me my right to a speedy trial), an order should be obtainable from a judge which forces me to decrypt.

If law enforcement took the first option, a cryptanalytic attack, when they bring the evidence gathered by that attack against me at trial, I should have the right to inquire, and get truthful answers, as to how the information was intercepted and how the decryption attack was performed. This goes back to questioning the methods of law enforcement, and it's perfectly valid for me to have this right. To have evidence thrown before me, and me not to have the right to question its source, is a gross infringement on my basic rights of due process.

I think this approach solves several problems with crypto law. The "decrypt it for us or go to jail" provision may seem heavy-handed, but remember that by the time I'm told that, a judge has been informed and has decided on probable cause. And I'm not just rotting in jail - presumably, my lawyer is appealing the order.

At the same time, accountability for law enforcement is maintained; evidence-gathering is subject to public scrutiny, and illegal wiretaps and decrypts of those wiretaps remain illegal, unusable at trial..

Dialog:

[kuro5hin]

Scenario One:

Government Authorities [Eyeing my big-ass, uncrackable safe]: Open that safe! We need the bad stuff you keep in there for evidence.

Me: No. Go to hell, pig.

G.A.: Ok, then, you go to jail for contempt of court until you open that safe!

----------------------

Scenario 2:

G.A. [Eyeing my encrypted HDD]: Decrypt that email! We need it for evidence.

Me: No. Go to hell, pig.

G.A.: Drat! We're useless without key escrow! Whinge whinge whinge... Me: Ha! Ha! I have won again...

Does this make any sense? Don't we already have laws for this? Hello?

----
We all take pink lemonade for granted.

Re:Solution

[HP LoveJet]

Better than that--certain cryptosystems (one-time pads are the most obvious example, but there are others) provide not only computational, but unconditional security when properly implemented.

Don't take my work for it; see D.R. Stinson, Cryptography: Theory and Practice , in which the information-theoretical underpinnings of unconditionally secure cryptography are explained in a way that anyone with a basic knowledge of probability can understand.

Then start doing your part to render the NSA irrelevant: Write Code.

Re:Solution

[um... Lucas]

I'm thinking that you're mixing up terms... 1024 bit assymetric encryption just involves big numbers, but it's no where near as hard to break as 128 bit symetric encryption... As factoring methods advance in combination with Moore's law, assymetic requirements will likely skyrocket However, symetric encrytion schemems (128-bit) will likely stand the test of time (so far as i understand it, barring and fundamental breakthroughs in computing)... 3000 bit assymetric keyts (like you find in PGP) are completely secure according to public knowledge today, and will be for the forseable future... even 768 bits is "good enough" for the next few years

Re:This is going to be just as expensive

[Todd Knarr]

The upshot? My (uninformed) prediction is this: There will still be 40-bit non-escrowed versions of the product going out the door. These will be shipped primarily to other countries and to paranoid individuals like slashdotters. Everyone else will run 128, but it will be a compromised breed of 128.

More likely, the rest of the world and the paranoid Slashdotters will use products developed outside the US, or products like Mozilla where we can bolt whatever crypto we want into the source and chuck any escrow that tries to creep in. The politicians seem to think the whole matter is a question of they can put the holes in they want. It isn't.

Re:Questions

[Teferi]

The open-source encryption software mentioned last week is called GPG (GNU Privacy Guard), and can be obtained from http://www.gnupg.org/. It was developed entirely outside the US, and therefore will be free from any restrictions bills such as SAFE place on crypto software.

Maybe I'm dense but...

[Otto]

"The failure to provide law enforcement with the necessary ability to obtain the plaintext version of the evidence makes existing authorities useless...Law enforcement has tools at its disposal to fight crime, but those tools are rendered useless when encryption gets involved"

Perhaps I don't understand. Free software ALREADY exists to do as good an unbreakable encryption as you want. If you are breaking the law already, what's to stop you from breaking it again, and simply, oh.. not giving away your private key to the escrow service? Hmmm? What the heck would law enforcement do then? Not a damn thing, because the evidence is encrypted! hah!

Key escrow is one of those things that can only hurt those who are honest enough to put their keys in escrow. Criminals wouldn't give away the key to their protected info to the law, just in case the law needed it to bust them! It simply makes no sense.

Silly politicians, privacy is for everyone!

---

Re:Stupid Laws

[Mr. Feely]

The most important aspect of a firearm is that it is one of the great equalizers...

This is one of the biggest pieces of BS used to justify gun ownership. I am no less "equal" to you if neither of us have guns than I am if both of us have guns. And frankly, I would rather live in a society where I don't have to carry a lethal weapon in order to be safe.

Besides, what about children? Should they be packing semi-automatic weapons so that they can be "equal" to the guy who decides to shoot up their preschool? And what about the the blind, or people with other disabilities? Firearms hardly qualify as the great equalizer for them.

For 95% of the US, firearms are an anachronism, but I'm afraid it'll take us another 100 years to realize it, if ever...

This is really bad for free software.

[chandoni]

This compromise between big computer companies and the government is fine for the companies... submitting to a code review and paying a one time fee in the tens of thousands of dollars is nothing compared to the hassle they go through now of maintaining separate domestic and exported versions. However, free software is usually continuously developed rather than being released in incremental versions, so each patch checked in would probably require a new code review. Also, free software developers (even if backed by RedHat) are rarely going to come up with that kind of money even once, much less if the fee was required every time a new version is released.

As the author said, the fight for looser encryption regulation is currently being led (and funded) by the commercial software industry lobby. If these guys become satisfied and drop out, there's no hope of ever getting US developers to be able to participate in GPG or other free encryption development projects.

JMC

Re:Pandora's box is open...

[colondot]

You're absolutely right, the US govt does not operate as a business, but, what we see here in the UK is a country that is behind the times, and is full of its own self importance. The US controlling the export regulations of encryption software is a sort of "well, no one outside the USA is intelligent enough to write crypto software", which is patent bull****!

When the US Govt get a grasp on this fact, then things might start to happen. Market and mind share is important, but not in quite the way that you percieve. No company really wants to be strong-armed into doing something because the government forces them to. So, if they incorporate offshore, then they don't have to be subject to US export restrictions, and they can do pretty much what they like. I think we will see companies who care doing something like this.

Re:Stupid Laws

[Saige]

it doesn't take years of training or great physical skill to use it properly

This is both a good AND a bad thing.

Learning a martial art gives you the ability to kill people, but along with it the discipline and understanding to keep you from using it in a moment of anger. A gun just gives you the ability to kill. And makes it easier to harm someone when you're upset.

Guns are not used only for killing -- the primary use is as a deterrent by posing a potential lethal threat. (The difference is subtle but extremely important.)

Nuclear weapons are not used only for killing -- the primary use is as a deterrent by posing a potential annihilatory threat. Doesn't make me change my mind about them. "Oh, it's ok that we have the potential to destroy all human life at the push of a button because we're not really going to use it." That doesn't cut it for me. The problem with having the threat is that it might be used. Especially that the threat might be used improperly.

And to bring it back around. You're still wrong. Guns are NOT the same as Encryption. You don't have to worry about someone stealing your encryption from you and harming people with it. You don't have to worry about your kids accidentally a hold of your encryption and killing themselves.

I'm not getting into this to talk about gun control. I'm just trying to say they are two TOTALLY different things.
---

Re: More answers... (info on SAFE)

[Esjion]

For information about SAFE (HR 850), as well as information about contacting members of Congress, check out the
Center for Democracy & Technology. If you put in your zip code, it will return information about your Rep. and how
to contact him/ her. Hope this helps!

Questions

[InSaNe ASyLuM]

Well, this article convinced me to try using the open source encryption software that was mentioned on /. a couple weeks ago... only problem is, I don't remember the name of it, or where to find it. Can anyone help me out?

Also, does anyone know anything about this SAFE bill? It sounds like something we should be telling our reps in Congress to support. Not that they ever really listen to us, but it can't hurt. It seems to me that with the readership that /. has, we could make for a pretty strong grassroots lobby on issues like this (if you're under 18, they don't really need to know that ;). Problem is, no one ever really bothers to try. I really think, that instead of always complaining about how the government is constantly trying to invade our privacy, we should be trying to do something about it. At least then when we complain about it, we can say we've tried to do our part. There was a site posted a bit ago with the e-mail addresses of Congressmen listed on it. Can someone post that again as well?

Solution

[TheKodiak]

I think I have a solution. Why not have every encrypted message use a secret key which, through a very lengthy process - several months, with several supercomputers at least - a government agency can break? That way, whenever they come across an encrypted message, if it is truly important, they can get into it, but the cost will be so prohibitive that they will never use it frivolously?

Oh - wait. That's pretty much the status quo, isn't it?

Anyway, don't real criminals have access to more secure methods of encrypting evidence, anyway? Like gasoline fires? I just don't see any reason for a backdoor that doesn't imply overly broad use.

Re:Solution

[substrate]

Sadly there's a good chance that that isn't the status quo for commercial products. With any sort of review process imposed by the government you can bet that the goal of the review is to have some way of recovering encrypted data. It may be as simple as a back door or it may be as subtle as reducing entropy during the encryption process. The measuring stick for passing the review process won't be: Is this software package protecting the interests of the consumer? It'll be: Can we recover encrypted data in an amount of time less than 'X', where 'X' is some duration which the various law enforcement agencies agree is acceptable.

The review process boils down to the ability of the government to hold a companies software for ransom until they deliver a product insecure enough to please the government but secure enough not to raise too many eyebrows among users.

Consumers will feel secure because they'll see "128 bit encryption" on the box and think "128 bits, thats pretty strong stuff" not realizing that it has somehow been compromised. It's a bit like allowing PGP for export without key length restrictions so long as any digits in the key beyond 128 are 0.

The other problem is that it will probably result in the weakening of security we already have. Right now for online banking you can use 128 bit encryption because browsers with that level of encryption are not allowed to be exported. Under the new legislation browsers will be allowed to be exported after the review process. If part of the review process is sufficiently weakening the encryption so that it isn't 'too difficult' to break then there will be a browser with the strength of 56 bits of encryption masquerading as 128 bits. Having two identical products both supporting 128 bit encryption wouldn't work (one with the real deal, one with the watered down version) since interoperability is required and something that crude could be easily discerned. Either the companies won't release '128 bit' encryption to foreign countries and lose potential revenue or they'll weaken the encryption and release the weakened version in both the US and overseas. Loyalty to stock holders implies that the ultimate decision won't be favorable for privacy.

Back doors

[Anonymous Coward]

Key point: by removing the requirement to show in court how they found an encryption key, and by still requiring software companies to get encryption software approved, they allow the government to strong-arm companies into building backdoors into encryption products--backdoors which will not be revealed in court when the government uses them to break encryption.

Re:How's that again?

[Anonymous Coward]

What this legislation seems to demand is a total war by the community against commercial crypto packages. This means, for instance, that if MS gets a license to export a crypto package for IE and NT, then there must be an effort to 1. crack it, and 2. look very hard for any backdoor. The saaame goes for crypto from IBM, SUN, Apple, and the rest of the commercial world.

If anybody finds a backdoor in any commercial product, then commercial crypto from the US is d-e-a-d. Nobody anywhere in the world will ever trust any crypto software emerging from the US ever ever again. Then, there will only be open source software from the community and there will be untrustoworthy crap.

another slap in the face to U.S. citizens

[Anonymous Coward]

This is one of those cases where special interests converge to work against the interests of the American public. Bob Goodlatte (and also Sen. Slade Gorton) are really pushing to remove some of the silly restrictions that we have right now. This would be good for both businesses AND the average citizen.

However, we keep running into the situation where powerful people in Washington D.C. decide that widespread strong cryptography is not in their best interest. Often these people are not even ELECTED officials (e.g. Louis Freeh). Yet their voice manages to drown out the little guy.

Worse yet, they wrap it in a nice little story about protecting YOU from terrorists. We are your officials, and we know (better than you) what is in your best interest.

What's scary is that these people know damn well that a key escrow system would be swiftly denounced by foreign nations. They aren't concerned about protecting Americans from terrorists. They are concerned about protecting their ability to eavesdrop on Americans.

The kicker here is that the White House says one thing and does another. Gore vows to reduce crypto restrictions, and yet everytime something remotely similar to SAFE is discussed, Clinton vows to veto it. I'm pretty sure he would too. Clinton isn't running for office...

What can I say. Yeah I'm a bit cynical. But all the newsgroup heckling and grumbling isn't going to do a bit of good. I hope everyone who reads this will consider focusing their energy by:

- writing or calling your senator or representative. Explain how important this is to you.

- joining/helping an organization that works to support your view, such as the EFF.

Just don't be silent.

Thanks,
SEAL

Pandora's box is open...

[hobbit]

...if the US government doesn't move quickly, it will seriously lose market- and mind-share in encryption products, without gaining any advantage in doing so (GPG and PGPi being freely importable).

To paraphrase a well-known comment:

"You have no access to our private communications anyway... get over it"

Hamish

Stupid Laws

[musique]

What always bothers me about these export laws is that if a Terrorist group really wanted to get a copy of some encryption software, they could have someone buy it in the US and mail a copy overseas, perhaps on a copied CD (or 10 different copies). I could think of a million other ways to do this. Mail it from Canada! Mexico! You can drive over without a thought. FTP it. XModem transfer it. How the hell is anyone going to know what is on it and that someone is breaking the law. Laws like this do not stop criminal elements from using the products, they just make it a tiny bit harder for them to get their hands on them.

This is the same with modern gun control legislation. Making guns illegal doesn't stop criminals from getting guns, only law-abiding citizens. There are now more guns in the US than their are people, and there is no stoping anyone from getting one. The same with weed, Same with computers, powerful microprocessors, and strong encryption. They can't be stopped!

Some are more equal than others

[jflynn]

If corporations are individuals, why do they get preferential treatment under the law, and effectively cast way more political influence than one vote? This "solution", a crypto review process not likely to be practicable for individuals or small businesses, or open source projects, is just the latest example.

This country seems to be falling into a dangerous mindset, optimizing law for corporations rather than individuals. Corporations need privacy. Individuals can't be allowed privacy (for their own good.)

Unfortunately, corporations are focused on making money in the short term no matter how expensive it proves to be for everyone else in the long term. Very little fundamental research is occurring in corporations as it once did at Bell Labs. Corporation mergers, acquisitions, and outsourcing have degraded our quality of life. A society organized for the sole benefit of the balance sheets of its corporations is not an optimal solution for individuals.

We should fight for equal rights for all under the law, individuals and corporations alike. One entity, one vote.

The true failure...

[devjoe]

Even if the bill is defeated, however, Internet users around the world should continue to be cautious about purchasing commercial encryption products that originate inside the U.S.; you never know what may be lurking within.

That the US government's muddled encryption policy has made US encryption products something to be wary of is the true failure of that policy.

Re:WTF? Confidentiality of method of decryption?

[Anonymous Coward]

That is a good point. I can assure you that the NSA doesn't care about J. Random Hacker. They only appeared on their radar screens in the early 80s. I know. I was one of them and had an ongoing relationship with them for several years because, frankly, I feel a lot more at home with them that with three-bong-hit revolutionaries who never bathe. I was struck then by a fact that made me grow up a lot, quickly. That is the fact that most people are, by definition, normal (yeah, really profound, I know), and that the curve that defines the vast majority of behavior is quite often steep and has very thin tails. This never varies. Never. Not across nations, cultures, or any other normal distribution. Never. The NSA, the FBI, the DPS -- whomever -- just don't care about 96-99% of all people because they don't and won't (ever) do anything really weird. Hackers fit into that same area, albeit with fatter tails on the curves. The NSA doesn't care because they know damned well that they don't have to. The CIA doesn't care because ... well, the CIA has its own problems, many of which they are having a hard time getting themselves out of. Suffice it to say that they aren't bugging your house either. That mathematical immutability of human behavior, apart from making the isolation of adolescence earier to cope with (I realized that I wasn't special, and that perverse fact made me feel much less isolated), is very well known to the spook community at large. They depend on it. They know it well. They also fear it because they know damned well that when they have a whole lot of people moving in one direction they are close to impossible to stop unless you use napalm. And that isn't very spooky.

The average cop on the beat (J. Random Officer), on the other hand, is not a math PhD. He probably has some college courses, possibly an undergraduate degree, limited classical education, and quite a bit of continuing education as a cop. The smart ones tend to move up -- the average cop has an IQ of 100-115, the average detective 130+, so most cops, generally, aren't too dumb, at leas these days, in larger departments, in larger cities. That does not, however, include cops who have been cops for twenty years, cops in many large cities who were hired for reasons other than competence (the old boy network, racial quotas, sex quotas, or the fact that the department needed people when they were out of work as a fry cook), cops in small town who never passed any formal screening, county/sherrif/constanble personnel, and that is still a lot of cops who will be in the system for years. That load of people for whom concepts like encryption are foreign will be much more of an issue because that, coupled with the fact that cops tend not to spend a lot of time learning (they are trying not to get killed or sued) and that they deeply mistrust anything new and complex due to years of experience with a liberal legal system screwing cops every chance it gets means that you are highly likely to run into someone who considers an encrypted partition to be prima facia evidence of wrongdoing should you ever run afoul of the law. I see this as a far greater issue than Ft. Mead listening to you talking to your love-muffin on your cell phone. The local PD and prosecutor are still easily able to out-spend most people, and defending your rights into bankruptcy is a real problem -- you should be able to, but suing people who have ruined you is hard if they work for the government is pretty tough. And most hackers aren't rich.

It will be interesting to see how this plays out. I would encourage all of you civic-minded hackers to offer to help your local police department. I have offered to help mine and give regular lectures on handling computers that are evidence, how not to handle hackers, and so on. It definitely has changed the attitude of a lot of the more senior and mossybacked cops who now see computers as less of a menace, and that is a good thing. Spread the information widely and offer to take the time to help and you will do a lot more good than if you complain bitterly and use 500000 bit keys, because the more people using encryption then the more chaff to sift, the more messages to log and batch, the more stuff to worry about -- and I can assure you that every cop I have lectured to is using PGP right now. Spread a little sunshine, like Linus did a few years back. It can only help.

Contains no meaningful penalties against misuse

[coats]

Reading through the bill, I see no meaningful penalties for misconduct on the government's part. I'd like to suggest a slashdot write-in suggestion to amend the bill to add a new section 2713(d) which states that for each improper disclosure of recovery information, of information obtained thereby, or for fraudulent testimony pursuant to the obtaining of an order under section 1712, all parties involved shall be individually liable for civil damages of $50,000 or treble damages, whichever is greater, plus court costs.

See how the Administration likes the bill then. As it stands, do you really expect the DOJ to slap its own hand when it breaks the law on this point?

WTF? Confidentiality of method of decryption?

[Tackhead]

I smell a rat here too. I mean, if I, as the prosecution, don't have to reveal to the court how I decrypted the "evidence", doesn't that give me just a wee bit too much power?

Testimony: "Your honor, as you can plainly see, the {kiddie porn, bombmaking instructions, drugmaking instructions, nuclear secrets} is on the client's hard drive. We just can't tell you how we decrypted it."

Reality: "Hey, Officer Crypto-Dude, can you XOR the suspect's scramdisk file of random noise with some {kiddie porn, bombmaking instructions, drugmaking instructions, nuclear secrets}? I really need a conviction, man!"

Hell, why bother creating a bogus one-time pad if you don't have to reveal the method? How about "Hey, Officer Crypto-Dude, gimme the files off the hard drive from the other guy we convicted last month."

If the prosecution doesn't have to disclose how it decrypted your files, the only defence you have against fabricated evidence is to give up your keys and divulge what was really on your hard drive. Damned if you do, damned if you don't.

As I wrote yesterday, I'm far more worried about corrupt cops than corrupt spooks. NSA knows it has better things to do with its time than invade your privacy. I'm not so convinced the same is true of Ms. Reno and Mr. Freeh.

Crytpo as munitions

[Cuthalion]

Does anyone know how crypto's classification as a munition interacts with our constitutional granted right to bear arms?

How's that again?

[Analog]

"The failure to provide law enforcement with the necessary ability to obtain the plaintext version of the evidence makes existing authorities useless."
"Law enforcement has tools at its disposal to fight crime, but those tools are rendered useless when encryption gets involved"

What bothers me most about comments like these is that they are based on the assumption that 'law enforcement' has an implicit right to have access to your information, as long as they feel the need. This is not so. A relevant passage:

"The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated"

Since when does building a back door into all communications qualify as secure? And a promise from law enforcement not to use it improperly is not security, even if they could make such a promise honestly; what happens when someone else figures out how to use the back door (and someone will)?

Another thing that I don't see being brought up much when statements like the above are being thrown about is history. People have been using various types of codes to encrypt sensitive communications for hundreds of years. Has law enforcement been 'useless' for all this time?

I find it (almost) amusing that one of the agencies screaming loudest about their need for this (the FBI) touts as their greatest victory the incarceration of a man who was convicted based on evidence they couldn't decipher. So what did they do? They offered the guy who knew what it meant a deal, and he did it for them. Is there some reason this doesn't work anymore?

This is going to be just as expensive

[konstant]

I work in crypto QA for a major, evil software company. Guess which one. We've been crossing our fingers for legislation like this due to the extreme cost and instability of shipping both a 128 and a 40/56 bit version of every crypto product. Apart from the effort of testing everything four times (once for hi, once for low, once for interactions, once for upgrades) there is the simple fact that as test matrices grow, bugs proliferate. And some are not found.

We used to say, "If only some bolt of light would strike Clinton upside the head and get him to liberate export policies!" Our premise was that the cost and difficulty of testing would drop, and we would be better situated to promote our client overseas.

NOPE. Even if this law passes, the labor of testing may just go up. Implementing a "backdoor" or a key escrow mechanism necessitates cracking the CSP's (oops - gave away which company) and re-writing practically the entire code structure that selects and manages algorithms. Easy? No. In addition, what foreign company would be interested in purchasing a product they know the US Government can abuse like a bitch at its will? I certainly wouldn't tolerate it.

The upshot? My (uninformed) prediction is this: There will still be 40-bit non-escrowed versions of the product going out the door. These will be shipped primarily to other countries and to paranoid individuals like slashdotters. Everyone else will run 128, but it will be a compromised breed of 128.

In other words, this will accomplish nothing other than weakening crypto for US citizens.

This bill is bullshit! Call or email your congressional office today. I'm about to do that very thing.
-konstant

Key escrow by definition is unsafe

[Zigg]

Yet another lovely step back in time by the Clinton administration. I wonder if any of the candidates for the next presidential election have gone on record for crypto policy.

The primary reason that the concept key escrow absolutely petrifies me is that the to be useful, the keys need to travel in one form or another from their central repository (which I would hope would be as tightly locked up as the NSA) to the law enforcement agency responsible for unlocking the message. With the repeated demonstrations by the U.S. Government that they don't understand crypto, what's even going to guarantee the safety of my key (and therefore my data) in transit?

Don't make me hand over my keys. I have them because they protect me. And you can bet that if key escrow becomes a requirement, I will not surrender my stock of open-source crypto software, but only begin to use it more.