IP: Admin Plans to Loosen Encryption Restrictions
--- begin forwarded text From: [EMAIL PROTECTED] Date: Tue, 14 Sep 1999 07:55:15 -0500 To: [EMAIL PROTECTED] Subject: IP: Admin Plans to Loosen Encryption Restrictions Sender: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Status: U Source: New York Times http://www.nytimes.com/library/tech/99/09/cyber/capital/14capital.html September 14, 1999 By JERI CLAUSING Administration Plans to Loosen Encryption Restrictions WASHINGTON -- The Clinton Administration, facing mounting pressure to eliminate controls on the export of encryption technology, is preparing to announce a further loosening of the controversial restrictions. The planned changes come on the heels of a report from a special presidential advisory committee recommending the White House abandon nearly all export controls on software that protects Internet communications. They also come as the House is preparing to debate a bill that would lift most controls on the export of products intended to keep computer communications and transactions secure. William Reinsch, the Undersecretary of Commerce and President Clinton's point man on encryption policy, declined to comment on the upcoming announcement or the advisory committee's report, which has not been made public. But he said the Administration's new policy would be announced by September 16. The changes, he said, are the "result of our own policy review," although he did acknowledge that the advisory commission report "was valuable input into that." That upcoming policy change comes exactly one year after Vice President Al Gore first announced the Administration was lifting controls on the export of strong encryption to certain business sectors, like banks and insurance companies, and was providing limited export relief for mass market products. At the time, Gore promised the Administration would review the controls again within a year. Since then, the Administration has come under continued pressure to move even further, both from Congress and the President's encryption advisory panel. In June, the President's Export Council Subcommittee on Encryption sent the White House a report recommending the Administration loosen its restrictions on encryption technology to allow for the export of consumer products based on a 128-bit key. That is significantly stronger than the current limit on encryption products exempt from control. The report also recommended allowing the export of a broad range of encryption products to online merchants who need powerful security systems to do business; eliminating approval requirements on exports to countries that "do not present a significant national security concern," and giving preferential treatment to exports aimed at utilities, telecommunications companies and other infrastructure sectors at risk of hacking attacks. White House and Commerce Department officials are keeping quiet about how far the policy changes will go. But if the changes reflect recommendations made in the advisory panel's report, it would move the Administration much closer to ending its years-long battle with the high-tech industry. Technology executives say they are losing their lead to companies in countries without export restrictions. The Administration has resisted calls to eliminate the restrictions because of strong opposition from the Federal Bureau of Investigation and other law enforcement agencies. Those groups have been pushing tying any easing of export restrictions to mandates that software developers develop "spare keys" so law officers can easily unlock scrambled data and communications when they suspect a crime is being committed. Stewart Baker, a member of the advisory panel and former counsel to the National Security Agency, characterized the committee's report as "the most sweeping set of liberalizations that have ever been recommended by a government advisory body." Although some who have been fighting the Administration's export controls doubt the planned changes will go far enough to effect a truce with House and Senate leaders pushing legislation to eliminate export controls entirely, Baker said he remained optimistic that substantial revisions would still be made. "I think it's in play," said Baker. "There's still some possibility that this will turn out to be a smaller package than some might hope, but it's still open." Ed Gillespie, executive director of Americans for Computer Privacy, a coalition of high-tech and civil libertarian groups that have for years been pushing for an elimination of all export controls on data-scrambling technology, said adoption of the advisory committee report by the White House would be significant. "But we don't know what to expect at this point. We're watching like everyone else," he said. "If it's good, great. If not, we'll continue to advocate change." This week: A special task force appointed by Congress to study Internet tax issues will hold its second meeting. The Advisory Commission on
Re: message-signing at the MTA level
On Sat, Aug 21, 1999 at 10:09:31PM -0400, Russell Nelson wrote: I've been thinking about cryptographic signing of messages at the mail transfer agent level. I can think of how to do it, but I'm not sure what problem it solves. :) Anyone have any ideas? At 12:01 PM 8/22/99 -0700, Eric Murray wrote: I wrote a similar system for Sun 4 or 5 years ago. However its purpose was to encrypt the email for secrecy. It used sendmail and PGP, would automagically encrypt messages sent to hosts/domains registered in a config file, and would use the same config file to attempt to decrypt incoming PGP'd messages. PGP/NAI developed an SMTP forwarder system that does rule-based processing with capabilities like - Encrypt outgoing mail when possible - Block unencrypted outgoing mail to some/all sites - Block encrypted outgoing mail to some/all sites - copy+encrypt in/outgoing mail to Corporate Email Escrow - Block outgoing mail not also encrypted to Corporate Escrow - Signdate incoming or outgoing mail This was during their Corporate Escrow period, so we all taunted them about it, rather than doing much thought about what things might be useful. Cryptographic signing of the messages can be useful in some business environments, though I'd prefer encryption+signing for many of them. If you always sign outgoing mail, and somebody asserts that an unsigned message is from your company, you've got some ability to argue that it's forged. More importantly, if someone knows you always sign your mail, and they receive unsigned mail claiming to be from you, you and they can be suspicious. One of the fun things about just doing signatures is that you can distribute the software for free if you want, without US export laws. A big problem with this, though, is making very sure that the software doesn't sign things it's not supposed to sign. This is hard, because it depends on the user's configuration of their mailserver and firewalls, which is mostly out of your control - having software with your name on it that gets abused this way would be Really Bad. Thanks! Bill Bill Stewart, [EMAIL PROTECTED] PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
Re: Power analysis of AES candidates
At 10:32 AM -0700 9/13/99, Eugene Leitl wrote: Why don't you just erase flash when a pressure change (hull breach) is detected. Using double-walled hull, to look for shortcuts. You can also couple this to light detection, and whatnot. Andreas Bogk writes: Russell Nelson [EMAIL PROTECTED] writes: There's some question about how hard it will be to design hardware that will be DPA-resistant for different algorithms. Big on-chip caps. Lithium batteries. Tamper-resistant housings. [...] A sophisticated attacker could measure the pressure in each compartment and work in a pressurized, darkened room. One thought I had is to include a circuit on chip (perhaps duplicated in several places) that would monitor on-chip supply voltage and keep the program from executing sensitive code for some period if dV/dt were too high. If the cap or Li battery were disconnected, the circuit would see continuous fluctuations and shut the processor down. A accidental power glitch would only cause a short delay in execution. If an attacker can get to the chip and disable these power monitor circuits, he can probably also put a logic analyzer on the memory lines and extract the key that way. Arnold Reinhold
Re: Power analysis of AES candidates
John Gilmore writes: What are you guys talking about? Differential power analysis doesn't require any physical attack, nor does it deal with voltage variations. (You are probably thinking of Shamir's fault-injection You can't do differential power analysis if you supply power photonically to an encapsulated unit. Power dissipated gets averaged out over time so you can't just monitor the temperature. attacks.) Differential power analysis measures the current consumption of the part as it operates, completely outside the device. 1) A self contained, sealed unit is immune to this 2) What prevents us from measuring the power fill out lacunes a la resistance heating? The unit would then show constant dissipation regardless of which computation it performs. It uses statistical techniques to confirm or reject hypotheses about the key values being operated on in the final rounds of encryption algorithms. Paul Kocher's team has developed some countermeasures, see the end of the technical discussion linked from: http://www.cryptography.com/dpa/index.html John
Re: Power analysis of AES candidates
At 01:35 PM 9/14/99 -0700, John Gilmore wrote: What are you guys talking about? Differential power analysis doesn't The power analysis thread mutated into a tamper-react thread without changing the Subject line. At 10:32 AM -0700 9/13/99, Eugene Leitl wrote: Why don't you just erase flash when a pressure change (hull breach) is Arnold Reinhold said: in several places) that would monitor on-chip supply voltage
Re: Power analysis of AES candidates
Andreas Bogk wrote: The usual setup for DPA involves a 10 Ohm resistor which sits in the power supply and measuring the voltage across that resistor. The countermeasure we're talking about is an on-chip capacitor that smoothes the power consumption, [...] Has this been analyzed? It's got to take the high-freqency information the attacker's looking for so far below the thermal noise floor that it can't recovered by averaging multiple runs. I do DSP, not EE, but I'd think this smoothing capacitor would effect a one-pole lowpass filter. If so, doubling the cap size halves the cutoff frequency (right?), halving the leaked power. Integrating runs gives signal voltage linear in n and noise voltage sqrt(n); voltage ratio is sqrt; power ratio is linear. So leaked-signal power is Theta( (attacker's number of runs) / (capacitor size) ). No asymptotic edge either way; attacker wins against bounded cap size. /handwave -- Eli Brandt | [EMAIL PROTECTED] | http://www.cs.cmu.edu/~eli/
Re: Power analysis of AES candidates
At 02:58 PM 9/14/99 -0700, Eugene Leitl wrote: You can't do differential power analysis if you supply power photonically to an encapsulated unit. Interesting. Such supplies have been proposed for medical gear, where you need absolute isolation. Intense light, reflector, Si cells. A few cm of air. Baroque and inefficient, yes..
RE: Paul Brown on Solitiare randomness flaw?
At 2:01 PM +0200 9/14/99, Kuehn, Ulrich wrote: Hi, please find here included a mail from Holger Klawitter, the author of one of the mentioned palm cipher programs... He would have liked to recieve the critique himself. Ulrich --- [quoted form Holger Klawitter [EMAIL PROTECTED]] http://www.klawitter.de/palm/cipher.html uses IDEA to encrypt the clipboard, but it's ascii armouring would make it hard to manually transmit ciphertext, if I understand what he is doing. One of the major drawbacks of the Palm pilot is the maximum length of a note which is 4096 bytes. ASCII Armouring makes text longer so I decided to use an armour with 7bit significance. If the demand proves to be more base 64 encoding I'll be happy to switch. Sorry, I was not critiquing Holger's program here, but rather considering its suitability for an application very different from its original purpose. The problem was how to enable a human rights worker in the field to send and receive coded messages. Such a worker might not have access to e-mail, so it is desirable that messages be capable of transmission via snail-mail, FAX, voice, Morse code, carved coconut shells or whatever. In this situation, even base-64 would be a pain. In its original contest, 7/8 encoding makes sense. Passphrase length is limited to 16 characters, which is unfortunate. Also, I wonder if the lack of a keyboard would make it a pain to enter persnickety text like passphrases and ciphertext. I think you've predicted my answer. In general, I think forcing a user to pick a short password is a bad idea. Even though entering a long password or passphrase on a Pilot is awkward, that choice should be left to the user. A password consisting of 16 random letters of the Roman alphabet offers 75 bits of entropy. That is adequate for strong security, but barely. If a user wants a strong passphrase that is easy to remember, 16 characters is hopeless. The consensus recommendation for long term security is 90 bits. To get that from 16 random characters, each character must be drawn from an alphabet of 50 symbols. Side note to document what some people really (believe to) want: I got some request for storing the passord in a database in order not to have to type it in so often. Of course, I denied the request :-) I agree that this is a dumb request if the program is only being used to protect files on the Pilot. But I wouldn't dismiss the suggestion quite so fast if the program is also being for communications security. One possible solution might be to allow two passwords, one of which is stored on the pilot in encrypted form, with the second password as the key. Arnold Reinhold
RE: Paul Brown on Solitiare randomness flaw?
Hi, please find here included a mail from Holger Klawitter, the author of one of the mentioned palm cipher programs... He would have liked to recieve the critique himself. Ulrich --- [quoted form Holger Klawitter [EMAIL PROTECTED]] http://www.klawitter.de/palm/cipher.html uses IDEA to encrypt the clipboard, but it's ascii armouring would make it hard to manually transmit ciphertext, if I understand what he is doing. One of the major drawbacks of the Palm pilot is the maximum length of a note which is 4096 bytes. ASCII Armouring makes text longer so I decided to use an armour with 7bit significance. If the demand proves to be more base 64 encoding I'll be happy to switch. Passphrase length is limited to 16 characters, which is unfortunate. Also, I wonder if the lack of a keyboard would make it a pain to enter persnickety text like passphrases and ciphertext. I think you've predicted my answer. Side note to document what some people really (believe to) want: I got some request for storing the passord in a database in order not to have to type it in so often. Of course, I denied the request :-) Gru? Holger -- Holger Klawitter +49 (0)251 484 0637 [EMAIL PROTECTED] http://www.klawitter.de/
