House committee ditches SAFE for law enforcement version
The text of the amendment (in PDF): http://www.house.gov/hasc/press.htm http://www.wired.com/news/news/politics/story/20872.html Industry Crypto Bill in Peril by Declan McCullagh 5:00 p.m. 21.Jul.99.PDT WASHINGTON -- And you thought Congress was going to override White House rules restricting US firms from exporting encryption products. Well, you were wrong. The House Armed Services Committee voted 47-6 Wednesday to replace an industry-endorsed encryption bill with substitute legislation drafted by law enforcement advocates. [...]
RE: Wireless Networking Encryption...
Well, if it is made by Lucent, then we are probably talking about WaveLAN. WaveLAN's used to offer a 56 bit DES chip option, but Lucent recently "upgraded" the crypto used to 40 bit RC4. Even issued a big press release about their new security features... BTW, if anybody ever finds a strong-crypto wireless LAN solution let me know. [To save time: yes, I am aware of IPSEC, SSL, etc. No, that's not what I am looking for. So please don't send me bunch of email suggesting it. I want the strong crypto built into the wireless LAN hardware]. Big thanks, --Lucky Green [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of K. M. Ellis Sent: Wednesday, July 21, 1999 11:59 To: Thomas P. Hallaran Cc: [EMAIL PROTECTED] Subject: Re: Wirelss Networking Encryption... Apple currently uses 56-bit DES in other password protected systems, such as the Users Groups Preferences file and for the Appleshare IP Web File Server application. I'd suspect that they use DES. A lot of their market share is overseas, so they're probably worried about crypto export law compliance. On 21 Jul 1999, Thomas P. Hallaran wrote: Apple computer just released a new wireless networking product, The "airport". This is from apple's web site: "Q. What kind of security does AirPort provide? A. AirPort offers password access control and encryption to deliver security equivalent to that of a physical network cable. Users are required to enter a password to log on to the AirPort network--and, optionally, an additional password for access to any other computer on the network. When transmitting information, AirPort uses 40-bit encryption to scramble data, rendering it useless to eavesdroppers." The product was actually developed by lucent tech. I wonder what kind of encryption is employed...? anyone know? - K. Ellis -- KB3CWP -- [EMAIL PROTECTED] - Meddle not in the affairs of sysadmins, for they are quick to anger and have not need for subtlety. - http://www.tux.org/~protozoa ---
Re: Wirelss Networking Encryption...
"tph" == Thomas P Hallaran [EMAIL PROTECTED] writes: tph Apple computer just released a new wireless networking product, tph The "airport". [...] tph The product was actually developed by lucent tech. I wonder what tph kind of encryption is employed...? anyone know? Jobs' keynote mentioned 40-bit encryption. michael
Re: House committee ditches SAFE for law enforcement version
Right. Some of the congresscritters who voted yesterday for the natsec version of SAFE were ostensible supporters of the business version. True, this particular natsec version of SAFE doesn't include domestic controls -- plenty of time for Freeh to try that later -- but export relief? Fuggetaboutit. The sponsor of yesterday's amendment, Rep. Weldon, said that he wants to have a classified briefing //on the House floor// to scare members into voting his way. Look for killer amendments to SAFE to be offered during that floor vote, perhaps even ones with domestic controls. But, heck, at least this fuss keeps business lobbyists, well, in business. (I was at an FTC hearing Tuesday and by the afternoon it was winding down, fairly useless panel discussions were dragging on. But a lobbyist for a multibillion Internet company told me he wasn't going to leave. "No fucking way -- I'm billing by the hour.") -Declan At 10:06 PM 7-21-99 -0700, Tim May wrote: http://www.wired.com/news/news/politics/story/20872.html Precisely what many of us have been saying for years would likely happen. The feebs in Congress are so uncommitted to fundamental philosophies that they really don't even know what they are voting on. A "War with Oceania" resolution can become a "War with Eastasia" resolution just because a couple of the feebs want to get out to the Chevy Chase Golf and Country Club to tee off.
Re: linux-ipsec: Re: TRNG, PRNG
John Denker writes: 1b') When the pool is depleted, /dev/urandom acts like a PRNG but reseeds itself in dribs and drabs as TRNG entropy becomes available. This leaves it vulnerable to an iterated guessing attack. The question is whether this is a realistic attack. 2a) Suppose some poor sysadmin leaves a *widely-readable* copy of the keyfile around somewhere, then fixes it by making it root-readable only, without being smart enough to totally reseed at that point. The system is shipped with the /dev/random state file protected 600, at least on Red Hat (see /etc/rc.d/init.d/random). It is reset to that state every startup and shutdown. A sysadmin would have to manually change that file's permissions after startup and then get his machine hacked. This seems pretty far-fetched. 2b) Suppose the attacker briefly gets root access. Such an attacker *could* do something much worse than merely reading the keyfile -- but might be afraid to. Altering the system has to be done very carefully or it will leave fingerprints. It's not really a matter of reading a "key file". The state file, /var/run/random-seed, saves random state from shutdown to startup. If an attacker read this shortly after boot he might be able to infer the present state, if little randomness had been added so far. However if the machine has been booted long enough ago that considerable randomness has come in, reading this file will not help. What he can do as root is to read the kernel memory and dump out the internal /dev/random pool itself. This is up to date, so he can then use the state-following attack if enough random data is being exposed to him and randomness comes in slowly enough. Given that he is doing this, he could probably patch the kernel in memory as well. Granted this takes a little more work, but if he is able to find the random pool in memory he can probably also find the kernel code. There are a number of changes he could make which would disable adding more entropy into the pool, for example, like patching a return instruction onto the entropy point for the function that actually adds entropy. It's questionable whether a redesign of /dev/random is necessary to deal with an attack where we have to assume that the attacker is pulling his punches like this. The ability to find the random pool in memory and dump it out is not that much less than the ability to patch out a few instructions. You're not raising the bar by much with this quantized reseeding layer. If it's really easy, okay, but don't kid yourself that you're gaining much safety.
