* [EMAIL PROTECTED] wrote on Fri, May 30, 2008 at 06:51 -0500:
Back in the day, DES was the de facto encryption algorithm.
[...]
In an ideal world, I think the system should throw an exception
then and let the calling application feed it another key.
However, I think the general consensus
On Thu, May 29, 2008 at 10:14:12AM -0400, Victor Duchovni wrote:
And then knowing that attackers never choose these keys, users start
using these keys because attakers avoid them, and then attackers start
checking these first again, ... This way lies madness. Fix your premise
and don't change
Yves Rutschle wrote:
On Wed, May 28, 2008 at 07:55:35PM +1200, Deane Sloan wrote:
Finally - how real is this concern? What is the probability that say a
2048bit generated key could fall into the 32,767 keys in the metasploit
SSH example on unaffected systems?
32,768 = 2^15
number of 2048 bit
* John Parker wrote on Sat, May 31, 2008 at 15:35 -0500:
Probability that a proper key falls in the space of the
bad debian keys: 2^15 / 2^2048 = 1 / 2^2033.
That's a lot of zeros before the first non-zero digit.
Put differently, if you were to start generating keys now at a rate
of,
On Wed, May 28, 2008 at 07:55:35PM +1200, Deane Sloan wrote:
Finally - how real is this concern? What is the probability that say a
2048bit generated key could fall into the 32,767 keys in the metasploit
SSH example on unaffected systems?
32,768 = 2^15
number of 2048 bit keys: 2^2048
On Sat, May 31, 2008 at 2:32 PM, Yves Rutschle [EMAIL PROTECTED] wrote:
On Wed, May 28, 2008 at 07:55:35PM +1200, Deane Sloan wrote:
Finally - how real is this concern? What is the probability that say a
2048bit generated key could fall into the 32,767 keys in the metasploit
SSH example on
On Sat, May 31, 2008 at 09:32:54PM +0200, Yves Rutschle wrote:
On Wed, May 28, 2008 at 07:55:35PM +1200, Deane Sloan wrote:
Finally - how real is this concern? What is the probability that say a
2048bit generated key could fall into the 32,767 keys in the metasploit
SSH example on
On Wed, May 28, 2008 at 08:01:11PM +0200, Ger Hobbelt wrote:
Anything (such as passwords) which has been used on an *actual*
'compromized box' (be it one of 'those Debian' releases or otherwise)
to _generate_ keys plus any keys _produced_ on such a compromised box
must be eradicated and are
On Thu, May 29, 2008 at 10:14:12AM -0400, Victor Duchovni wrote:
And then knowing that attackers never choose these keys, users start
using these keys because attakers avoid them, and then attackers start
checking these first again, ... This way lies madness. Fix your premise
and don't change
On Wed, May 28, 2008 at 10:55:18PM -0700, David Schwartz wrote:
Okay, I guess I give up. I now realize that I had no idea what
you meant in your past few comments. What relevance do you think
this notion of weak keys has to do with this issue, since you
were the one who brought it up?
The
On Friday 30 May 2008 07:39:08 [EMAIL PROTECTED] wrote:
I personally don't like the idea of generating keys that people will
try, or using a weak/known key with small probability, but in this
case I think it's so small that simply scanning for and banning such
keys is good enough.
I was
On Friday 30 May 2008 07:39:08 [EMAIL PROTECTED]
wrote:
I personally don't like the idea of generating keys that people will
try, or using a weak/known key with small probability, but in this
case I think it's so small that simply scanning for and banning such
keys is good enough.
What
Travis wrote:
Agreed.
Let's assume that users tend to pick the password password when
given a choice.
Now adversaries try the most common password, namely password, first.
Security conscious admins ban the word password as a password.
Yes, this does reduce the keyspace a tiny bit.
Do
On Wed, May 28, 2008 at 6:47 PM, Deane Sloan [EMAIL PROTECTED] wrote:
To tie this off - is it fair to say that the impact of say 2048bit RSA
SSL(etc) using a private key in the affected range is a valid
consideration/concern, however in combination with the likelihood
stated, the overall risk
* Victor Duchovni wrote on Wed, May 28, 2008 at 21:10 -0400:
Only against random attacks of course, if all attackers
first check these keys, then removing them strengthens the
algorithm against (non-random) brute-force attack. This
said, the effort of explicitly avoiding these is
On Thu, May 29, 2008 at 09:48:38AM +0200, Steffen DETTMER wrote:
On the other hand, someone else could assume that all potentially
weak keys are regenerated and the concerned (boxes,
systems, admins, security professionals, ...) now are more
sensitive, carefully exchanged all keys against,
Only against random attacks of course, if all attackers first check these
keys, then removing them strengthens the algorithm against (non-random)
brute-force attack. This said, the effort of explicitly avoiding these
is probably wasted (unless one suspects one has a identically weak RNG).
--
Hi,
Regarding the recently reported Debian patch of OpenSSL issue, the
affected keys would seem to be well known and with the metasploit site
hosting pre-computed keys and a number of scripts around various sites
available to take advantage of the specific problem, it would seem like
just a
On Wed, May 28, 2008 at 07:55:35PM +1200, Deane Sloan wrote:
Finally - how real is this concern? What is the probability that say a
2048bit generated key could fall into the 32,767 keys in the metasploit
SSH example on unaffected systems?
This concern is unwarranted.
--
Viktor.
Finally - how real is this concern? What is the probability that say a
2048bit generated key could fall into the 32,767 keys in the metasploit
SSH example on unaffected systems?
Best Regards,
Deane
If you think about it, it doesn't make sense. Suppose I include a randomish
string in my
On Wed, May 28, 2008 at 08:09:16AM -0700, Michael Sierchio wrote:
David Schwartz wrote:
... Suppose I include a randomish
string in my message 46e8bd8ceae57f8b7af66536e7859bad. Any attacker might
see this message -- it's public. So he can certainly try that string as
your
password. So
David Schwartz wrote:
... Suppose I include a randomish
string in my message 46e8bd8ceae57f8b7af66536e7859bad. Any attacker might
see this message -- it's public. So he can certainly try that string as your
password. So will you now run off and add it to a blacklist, since it's
clearly now a
and
kerosene...
Thanks again,
Deane
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Victor Duchovni
Sent: Thursday, May 29, 2008 3:37 AM
To: openssl-users@openssl.org
Subject: Re: Wider fallout from Debian issue?
On Wed, May 28, 2008 at 08:09:16AM -0700
* Deane Sloan wrote on Thu, May 29, 2008 at 04:47 +1200:
stated, the overall risk of generating such a key on an unaffected
system is (extremely?) small for the security that a 2048bit RSA private
key is intended for?
The risk to generate one specific key of 2^16 (or how small was
the key
David Schwartz wrote:
... Suppose I include a randomish
string in my message 46e8bd8ceae57f8b7af66536e7859bad. Any
attacker might
see this message -- it's public. So he can certainly try that
string as your
password. So will you now run off and add it to a blacklist, since it's
On Wed, May 28, 2008 at 03:38:47PM -0700, David Schwartz wrote:
In principle, specifically avoiding these keys weakens the algorithm by
reducing the keyspace.
Only against random attacks of course, if all attackers first check these
keys, then removing them strengthens the algorithm against
On Wed, May 28, 2008 at 03:38:47PM -0700, David Schwartz wrote:
In principle, specifically avoiding these keys weakens the
algorithm by reducing the keyspace.
Only against random attacks of course, if all attackers first check these
keys, then removing them strengthens the algorithm
On Wed, May 28, 2008 at 04:31:20PM -0700, David Schwartz wrote:
Only against random attacks of course, if all attackers first check these
keys, then removing them strengthens the algorithm against (non-random)
brute-force attack. This said, the effort of explicitly avoiding these
is
David Schwartz wrote:
Every known key, provided there are not too many known keys, is weak.
Once again, you have a very idiosyncratic lexicon of cryptographic
terms. How about if we use these words the way cryptographers do?
A weak key is one that causes a cipher to leak private data in the
David Schwartz wrote:
Every known key, provided there are not too many known keys, is weak.
Once again, you have a very idiosyncratic lexicon of cryptographic
terms. How about if we use these words the way cryptographers do?
A weak key is one that causes a cipher to leak private
30 matches
Mail list logo
