Re: A mighty fortress is our PKI, Part II

2010-07-29 Thread Pat Farrell
On 07/28/2010 08:44 PM, Steven Bellovin wrote: When I look at this, though, little of the problem is inherent to PKI. Rather, there are faulty communications paths. You note that at t+2-3 days, the CA read the news. Apart from the question of whether or not 2-3 days is shortly after -- the

Re: Fwd: Introduction, plus: Open Transactions -- digital cash library

2010-07-29 Thread Ian G
Hi Bob, On 28/07/10 9:08 PM, R.A. Hettinga wrote: Anyone out there with a coding.clue wanna poke inside this thing and see if it's an actual bearer certificate -- and not yet another book-entry -- transaction system? Sorry to get your hopes up ... Just reading the words below not the

Re: A mighty fortress is our PKI, Part II

2010-07-29 Thread Alexandre Dulaunoy
On Thu, Jul 29, 2010 at 3:09 AM, Nicolas Williams nicolas.willi...@oracle.com wrote: This is a rather astounding misunderstanding of the protocol.  An OCSPResponse does contain unauthenticated plaintext[*], but that plaintext says nothing about the status of the given certificates -- it only

Re: A mighty fortress is our PKI, Part II

2010-07-29 Thread James A. Donald
On 2010-07-29 12:18 AM, Peter Gutmann wrote: This does away with the need for a CA, because the link itself authenticates the cert that's used. Then there are other variations, cryptographically generated addresses, ... all sorts of things have been proposed. The killer, again, is the refusal

Re: deliberately crashing ancient computers (was: Re: A mighty fortress is our PKI)

2010-07-29 Thread Jerry Leichter
On Jul 28, 2010, at 11:04 AM, Jonathan Thornburg wrote: http://www.crashie.com/ - if you're feeling malicious, just include the one line JavaScript that will make IE6 crash, maybe eventually the user will figure it out. (Or maybe not). Please stop and think about the consequences before

SHA256 reduced to 112 bits?

2010-07-29 Thread Paul Wouters
Hi, I've heard rumors of an attack on the SHA-2 family reducing complexity of SHA256 to something less or equal of 112 bits. This attack will apparently be announced in a few days - perhaps at Black Hat or Def Con? I would be interested in knowing more. Paul

Re: A mighty fortress is our PKI, Part II

2010-07-29 Thread Anne Lynn Wheeler
On 07/28/2010 11:52 PM, Pat Farrell wrote: I'd like to build on this and make a more fundamental change. The concept of a revocation cert/message was based on the standard practices for things like stolen credit cards in the early 1990s. At the time, the credit card companies published telephone

Re: A mighty fortress is our PKI, Part II

2010-07-29 Thread StealthMonger
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jerry Leichter leich...@lrw.com writes: The only conceivable purpose for using a signature is that you can check it *offline*. If you assume you can connect to the network, and that you can trust what you get from the network - why bother with a

Re: A mighty fortress is our PKI, Part II

2010-07-29 Thread Nicolas Williams
On Thu, Jul 29, 2010 at 10:50:10AM +0200, Alexandre Dulaunoy wrote: On Thu, Jul 29, 2010 at 3:09 AM, Nicolas Williams nicolas.willi...@oracle.com wrote: This is a rather astounding misunderstanding of the protocol.  [...] I agree on this and but the implementation of OCSP has to deal with

Obama administration seeks warrantless access to email headers.

2010-07-29 Thread Perry E. Metzger
Quoting: The administration wants to add just four words -- electronic communication transactional records -- to a list of items that the law says the FBI may demand without a judge's approval. Government lawyers say this category of information includes the addresses to which an

Persisting /dev/random state across reboots

2010-07-29 Thread Richard Salz
At shutdown, a process copies /dev/random to /var/random-seed which is used on reboots. Is this a good, bad, or shrug, whatever idea? I suppose the idea is that all startup procs look the same ? tnx. -- STSM, WebSphere Appliance Architect

Re: A slight modification of my comments on PKI.

2010-07-29 Thread Anne Lynn Wheeler
On 07/28/2010 10:34 PM, d...@geer.org wrote: The design goal for any security system is that the number of failures is small but non-zero, i.e., N0. If the number of failures is zero, there is no way to disambiguate good luck from spending too much. Calibration requires differing outcomes.

Re: Persisting /dev/random state across reboots

2010-07-29 Thread Thierry Moreau
Richard Salz wrote: At shutdown, a process copies /dev/random to /var/random-seed which is used on reboots. Is this a good, bad, or shrug, whatever idea? I suppose the idea is that all startup procs look the same ? tnx. First look at http://en.wikipedia.org/wiki/Urandom There is a

Re: Persisting /dev/random state across reboots

2010-07-29 Thread Nicolas Williams
On Thu, Jul 29, 2010 at 03:47:01PM -0400, Richard Salz wrote: At shutdown, a process copies /dev/random to /var/random-seed which is used on reboots. Is this a good, bad, or shrug, whatever idea? If the entropy pool has other, reasonable/fast sources of entropy at boot time, then seeding the

Re: Persisting /dev/random state across reboots

2010-07-29 Thread Paul Wouters
On Thu, 29 Jul 2010, Richard Salz wrote: At shutdown, a process copies /dev/random to /var/random-seed which is used on reboots. Is this a good, bad, or shrug, whatever idea? I suppose the idea is that all startup procs look the same ? better then not. A lot of (pseudo)random comes from disk

Re: A slight modification of my comments on PKI.

2010-07-29 Thread Anne Lynn Wheeler
for the fun of it ... from today ... Twenty-Four More Reasons Not To Trust Your Browser's Padlock http://blogs.forbes.com/firewall/2010/07/29/twenty-four-more-reasons-not-to-trust-your-browsers-padlock/?boxes=Homepagechannels from above: On stage at the Black Hat security conference Wednesday,

Re: Persisting /dev/random state across reboots

2010-07-29 Thread John Denker
On 07/29/2010 12:47 PM, Richard Salz wrote: At shutdown, a process copies /dev/random to /var/random-seed which is used on reboots. [1] Actually it typically copies from /dev/urandom not /dev/random, but we agree, the basic idea is to save a seed for use at the next boot-up. Is this a