Intel is looking for Info Security interns

2000-04-27 Thread John Gilmore
From: "McGregor, Pat" <[EMAIL PROTECTED]> Subject: We are looking for Interns Date: Wed, 26 Apr 2000 08:59:48 -0700 Information Security at Intel has two more intern slots to fill for this summer, based in Phoenix, Folsom, Oregon. The interns will work on tool development, management projects, a

Echelon article in the Economist

2000-04-27 Thread P.J. Ponder
From: The Economist Online edition Apr 29th - May 5th 2000 Those perfidious Anglo spies Allegations that Britain helps America and others spy on its European allies have annoyed some across the Channel This is an Anglo-Saxon Protestant conspiracy. So much for Britain’s commitment to European

Re: key agility and IPsec

2000-04-27 Thread Barney Wolff
While computations on averages can prove that a design will not work, they obviously cannot prove that it will. I submit that the more interesting data is how long trains of minimum-size packets are, and how far behind an actual crypto engine can get before it runs out of buffers. But in a certa

Updated A5/1 Paper

2000-04-27 Thread John Young
Adi Shamir has provided "Real Time Cryptanalysis of A5/1 on a PC," an 18-page paper by Alex Biryukov, Adi Shamir and David Wagner presented at the Fast Encryption Software Workshop in New York City on April 10. It is an updated version of the December 1999 preliminary draft by Biryukov and Sham

Re: key agility and IPsec

2000-04-27 Thread Steven M. Bellovin
I should have added one further point to my note. In one respect, my figures do support your position. The upstream traffic, which was required a larger cache, was also a significantly slower stream, both in packets and in bytes. That provides a lot more headroom for key setup. And while th

Re: key agility and IPsec

2000-04-27 Thread Steven M. Bellovin
In message <[EMAIL PROTECTED]>, Ron Rivest writes: > >Steve -- > >Don't your statistics support the argument that key agility is >*not* likely to be terribly important by itself? > >With a cache capable of storing only 5 key setups, you get at least a >75% hit rate, by your statistics. > >This e

Intel nixes ID tracking numbers in future 1.5 GHz Willamette chip

2000-04-27 Thread Declan McCullagh
** Background: http://www.politechbot.com/cgi-bin/politech.cgi?name=intel ** http://www.wired.com/news/politics/0,1283,35950,00.html Intel Nixes Chip-Tracking ID by Declan McCullagh ([EMAIL PROTECTED]) 3:00 a.m. Apr. 27, 2000 PDT Hoping to avoid another campaign by priv

key agility and IPsec

2000-04-27 Thread Steve Bellovin
(Note to ipsec@ readers -- this is a follow-up to a discussion on the cryptography list a week or so ago. To spare folks who subscribe to both, I've directed followups to the cryptography list ONLY. Subscription to it is via [EMAIL PROTECTED]) Following my exchange of notes with Ron Rive

MS on NSA_KEY in Windows

2000-04-27 Thread John Young
Duncan Campbell has provided a recent exchange of informative messages with Scott Culp at Microsoft on the origin, function and purpose of NSA_KEY in Windows: http://cryptome.org/nsakey-ms-dc.htm

Re: key agility and IPsec

2000-04-27 Thread Ron Rivest
Steve -- Don't your statistics support the argument that key agility is *not* likely to be terribly important by itself? With a cache capable of storing only 5 key setups, you get at least a 75% hit rate, by your statistics. This effectively reduces key setup time by a factor of *four*, maki

Re: key agility and IPsec

2000-04-27 Thread Ron Rivest
(Following earlier posting by Steve Bellovin and myself on the same subject.) Steve -- I don't quite understand your argument yet, although it is certainly good to have some data to look at! We can have a simple model for encryption time wherein c + d n to encrypt a packet of n bytes