PGP key server changes [was: RE: 1024-bit RSA keys in danger of compromise]

2002-03-29 Thread Lucky Green

 
Enzo wrote:
 Hmmm... I see that the new 4096-bit super-duper key, besides 
 its own (which doesn't prove much), only bears the signatures 
 of the now revoked -as potentially compromised- old keys 
 0x375AD924 and 0xEEE8CFF3, plus 0x06757D2D (which turns out 
 to be a 1024-bit DSA key) and 0x50C0FEA7 (a lowly 2048-bit 
 RSA legacy key)...
 
 Are you really our Lucky, or the NSA proving our worst fears 
 founded? ;-)

Oh, the curse of having to revoke a key that accumulated years of WOT
signatures...

My new pub key has since acquired a few signatures. You can always
get the latest version of my key by fingering [EMAIL PROTECTED]
or via LDAP from ldap://pgp.surfnet.nl:11370 (also known as
europe.keys.pgp.com, though this alias may not last much longer given
that it seems that the canonical PGP keyserver at keyserver.pgp.com
appears to already have ceased operations in the wake of NAI placing
PGP into maintenance mode. At least I have been unable to connect
to that server for several days now. YMMV).

No, my new key will not interoperate with PGP 1.0, Bass-O-Matic, or
similarly outdated versions of PGP. Readers of this post are
discouraged from contacting me to inform me of this fact. I an well
aware of it and couldn't care less. Few, if any, programs that I use
today would run on the Macintosh DUO 230 on which I generated my
first 1024-bit PGP key back when I was an alpha tester for PGP 2.0.
Thanks to Moore's Law, my first-ever 1024-bit key took a hell of a
lot longer to generate on what was then a brand new machine than it
took to generate my new 4096-bit PGP key on the old K6-333 that I
used a few days ago to generated not only my new PGP key, but various
4096-bit SSH keys for good measure.

My suggestion would be to use the time saved by not sending me such
an email to upgrade your version of PGP instead. The key has been
tested to work fine with the current release versions of PGP for
Windows and Mac as well as GnuPG for UNIX and I presume Windows,
though I haven't tested GnuPG on Windows.

Those of you that know me are very much encouraged to contact me to
verify the fingerprint of my new key. If you have my personal mobile
phone number, just call. If you don't, email me for the number. Since
I would rather not post it to a public mailing list.

--Lucky



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



Re: 1024-bit RSA keys in danger of compromise

2002-03-29 Thread V Alex Brennen

On Mon, 25 Mar 2002, Bill Stewart wrote:

 While SSL implementations are mostly 1024 bits these days,
 aren't PGP Diffie-Hellman keys usually 1536 bits?

I think there's a general consensus that the minimum
recommended key size for X9.42 Diffie-Hellman PGP keys 
is 1024bits.  I'm not sure if the standard size is 1536bits.
I  might be wrong, but I don't believe such a key length
standard exists. I think the only size related limitation
in X9.42 was related only to size of the prime defining
the Galos Field.  I haven't worked with X9.42 before.

There does not appear to be many 1536bit keys in the global PGP
public keyring (the keys of the synchronized public keyservers).

I count 1,057 in my copy of the ring, or 0.0748% of the
total keys in the ring.

Here is more information about that ring:

http://gnv.us.ks.cryptnet.net/stats.html

Notice the % of keys which is = 1024bits. 


- VAB
---
V. Alex Brennen
Senior Systems Engineer
IBM Certified Specialist
e-TechServices.com
IBM Business Partner
Bus: 352.246.8553
Fax: 770.216.1877
[EMAIL PROTECTED]
http://www.e-techservices.com/people/vab/


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



Re: 1024-bit RSA keys in danger of compromise

2002-03-28 Thread Bill Stewart

At 05:38 PM 03/23/2002 -0800, Lucky Green wrote:
While the latter doesn't warrant comment, one question to ask
spokespersons pitching the former is what key size is the majority of
your customers using with your security product? Having worked in this
industry for over a decade, I can state without qualification that
anybody other than perhaps some of the HSM vendors would be misinformed
if they claimed that the majority - or even a sizable minority - of
their customers have deployed key sizes larger than 1024-bits through
their organization. Which is not surprising, since many vendor offerings
fail to support larger keys.

While SSL implementations are mostly 1024 bits these days,
aren't PGP Diffie-Hellman keys usually 1536 bits?



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



Re: 1024-bit RSA keys in danger of compromise

2002-03-28 Thread Eric Murray



Here's the distribution of RSA key sizes in SSL servers, as
recorded by my SSL server survey in June 2000 and June 2001

RSA Server Key size
   Key bits2000 2001
2048 .2% .2%
1024   70% 80%
= 1000 2%   .7%
= 768  2%   1%
512 -   0%
= 512  25% 17%



Eric



-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



Re: 1024-bit RSA keys in danger of compromise

2002-03-25 Thread A. Melon

Please note the following follow-up message on cypherpunks from
Ian Goldberg:

From: [EMAIL PROTECTED] (Ian Goldberg)
Subject: CDR: Re: 1024-bit RSA keys in danger of compromise
Date: 24 Mar 2002 18:08:32 GMT

In article 00e101c1d2d8$c9768080$c33a080a@LUCKYVAIO,
Lucky Green [EMAIL PROTECTED] wrote:
The panel, consisting of Ian Goldberg and Nicko van Someren, put forth
the following rough first estimates:

I'd just like to credit the O(minutes) calculation to Nicko;
my own opinion was that:

- We have no reason to believe the asymptotic result applies to real
  keylengths (2^1024  infinity)
- The physical properties of such a machine (size, power, cooling, etc.)
  seem implausible to me.

I personally don't intend to be revoking my 1024 bit key at this time.

   - Ian

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



Re: 1024-bit RSA keys in danger of compromise

2002-03-25 Thread Enzo Michelangeli

- Original Message -
From: Lucky Green [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, 24 March, 2002 9:38 AM
Subject: 1024-bit RSA keys in danger of compromise


[...]
 In light of the above, I reluctantly revoked all my personal 1024-bit
 PGP keys and the large web-of-trust that these keys have acquired over
 time. The keys should be considered compromised. The revoked keys and my
 new keys are attached below.

Hmmm... I see that the new 4096-bit super-duper key, besides its own (which
doesn't prove much), only bears the signatures of the now revoked -as
potentially compromised- old keys 0x375AD924 and 0xEEE8CFF3, plus 0x06757D2D
(which turns out to be a 1024-bit DSA key) and 0x50C0FEA7 (a lowly 2048-bit
RSA legacy key)...

Are you really our Lucky, or the NSA proving our worst fears founded? ;-)

Enzo




-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]



1024-bit RSA keys in danger of compromise

2002-03-24 Thread Lucky Green

As those of you who have discussed RSA keys size requirements with me
over the years will attest to, I always held that 1024-bit RSA keys
could not be factored by anyone, including the NSA, unless the opponent
had devised novel improvements to the theory of factoring large
composites unknown in the open literature. I considered this to be
possible, but highly unlikely. In short, I believed that users' desires
for keys larger than 1024-bits were mostly driven by a vague feeling
that larger must be better in some cases, and by downright paranoia in
other cases. I was mistaken.

Based upon requests voiced by a number of attendees to this year's
Financial Cryptography conference http:/www.fc02.ai, I assembled and
moderated a panel titled RSA Factoring: Do We Need Larger Keys?. The
panel explored the implications of Bernstein's widely discussed
Circuits for Integer Factorization: a Proposal.
http://cr.yp.to/papers.html#nfscircuit

Although the full implications of the proposal were not necessarily
immediately apparent in the first few days following Bernstein's
publication, the incremental improvements to parts of NFS outlined in
the proposal turn out to carry significant practical security
implications impacting the overwhelming majority of deployed systems
utilizing RSA or DH as the public key algorithms.

Coincidentally, the day before the panel, Nicko van Someren announced at
the FC02 rump session that his team had built software which can factor
512-bit RSA keys in 6 weeks using only hardware they already had in the
office.

A very interesting result, indeed. (While 512-bit keys had been broken
before, the feasibility of factoring 512-bit keys on just the computers
sitting around an office was news at least to me).

The panel, consisting of Ian Goldberg and Nicko van Someren, put forth
the following rough first estimates:

While the interconnections required by Bernstein's proposed architecture
add a non-trivial level of complexity, as Bruce Schneier correctly
pointed out in his latest CRYPTOGRAM newsletter, a 1024-bit RSA
factoring device can likely be built using only commercially available
technology for a price range of several hundred million dollars to about
1 billion dollars. Costs may well drop lower if one has the use of a
chip fab. It is a matter of public record that the NSA as well as the
Chinese, Russian, French, and many other intelligence agencies all
operate their own fabs.

Some may consider a price tag potentially reaching $1B prohibitive. One
should keep in mind that the NRO regularly launches SIGINT satellites
costing close to $2B each. Would the NSA have built a device at less
than half the cost of one of their satellites to be able to decipher the
interception data obtained via many such satellites? The NSA would have
to be derelict of duty to not have done so.

Bernstein's machine, once built, will have power requirements in the MW
to operate, but in return will be able to break a 1024-bit RSA or DH key
in seconds to minutes. Even under the most optimistic estimates for
present-day PKI adoption, the inescapable conclusion is that the NSA,
its major foreign intelligence counterparts, and any foreign commercial
competitors provided with commercial intelligence by their national
intelligence services have the ability to break on demand any and all
1024-bit public keys.

The security implications of a practical breakability of 1024-bit RSA
and DH keys are staggering, since of the following systems as currently
deployed tend to utilize keys larger than 1024-bits:

- HTTPS
- SSH
- IPSec
- S/MIME
- PGP

An opponent capable of breaking all of the above will have access to
virtually any corporate or private communications and services that are
connected to the Internet.

The most sensible recommendation in response to these findings at this
time is to upgraded your security infrastructure to utilize 2048-bit
user keys at the next convenient opportunity. Certificate Authorities
may wish to investigate larger keys as appropriate. Some CA's, such as
those used to protect digital satellite content in Europe, have already
moved to 4096-bit root keys.

Undoubtedly, many vendors and their captive security consultants will
rush to publish countless reasons why nobody is able to build such a
device, would ever want to build such a device, could never obtain a
sufficient number of chips for such a device, or simply should use that
vendor's unbreakable virtual onetime pad technology instead.

While the latter doesn't warrant comment, one question to ask
spokespersons pitching the former is what key size is the majority of
your customers using with your security product? Having worked in this
industry for over a decade, I can state without qualification that
anybody other than perhaps some of the HSM vendors would be misinformed
if they claimed that the majority - or even a sizable minority - of
their customers have deployed key sizes larger than 1024-bits through
their organization. Which is not