Received: by 10.68.73.229 with SMTP id o5mr4012638pbv.7.1329407056302;
        Thu, 16 Feb 2012 07:44:16 -0800 (PST)
Path: wr5ni32276pbc.0!nntp.google.com!news1.google.com!eweka.nl!lightspeed.eweka.nl!194.134.4.91.MISMATCH!news2.euro.net!feeds.phibee-telecom.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Stuart Barkley <stua...@4gh.net>
Newsgroups: sci.crypt
Subject: Re: Analysis of public keys ("Ron was wrong, Whit is right")
Date: Thu, 16 Feb 2012 10:44:08 -0500
Organization: A noiseless patient Spider
Lines: 35
Message-ID: <alpine.BSF.2.00.1202161024470.51627@freeman.4gh.net>
References: <87vcn9azfm.fsf@cenderis.demon.co.uk>
Mime-Version: 1.0
Injection-Info: mx04.eternal-september.org; posting-host="Z6sO+uu0/Ue19J/YKJa6rw";
	logging-data="3667"; mail-complaints-to="ab...@eternal-september.org";	posting-account="U2FsdGVkX18EUkGsaaIBQZ0Z23RsI3MP"
In-Reply-To: <87vcn9azfm.fsf@cenderis.demon.co.uk>
Cancel-Lock: sha1:NXLxpv+LLZ5N4IzGvAxzy//TtWI=
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 14 Feb 2012 at 16:16 -0000, Bruce Stephens wrote:

> Cool and surprising (to me, anyway) research:
> <http://eprint.iacr.org/2012/064.pdf>

I suspect that a bigger problem is just the escaping of the private
key out of the secure environment.  Someone may put it in a shared
revision control system, it may go into the internal wiki as part of
installation instructions to be performed by operations staff, it
might get emailed from one person to another.

Most security professionals would attempt to prevent this from
happening, but I have to believe that far less then 99.8% of the
secrets ever meet a security professional.

> A non-trivial number of RSA public keys are actually shared by
> apparently unrelated entities, and a larger proportion share a
> factor with another public key (allowing both to be factored).

This is one reason I try to resist the concept of "I don't want to
bother with this ever again, just set the expiration date way in the
future".  Of course, when the certs (self signed or not) expire, the
users will still just accept them.

Also, I like to roll secrets periodically.  This can improve security
by making use of process improvements in the generation of keying
material.  In addition, it can deal with any leaks of the previous
secrets or flaws in the early generation/storage of secrets (key
generation gets done early in new system installations and may not
receive the care it needs).

Stuart
-- 
I've never been lost; I was once bewildered for three days, but never lost!
                                        --  Daniel Boone