* Bodo Moeller:
BTW, it appears that the same blacklist can be used for -3 and -F4 keys.
(Just in case you haven't checked that already.)
A more elaborate explanation seems in place to make sure that
we avoid uninentionally incomplete blacklists.
Thanks, I've added a warning if an e !=
On Wed, 21 May 2008, Jan Tomasek wrote:
Jamie Strandboge wrote:
I discovered that there is also 3rd key which you get if you pass
empty file by -rand. Keys created in this way are still the same so
it's another possible compromised key. I'm not sure if it worth
spend time on counting
On Wed, 21 May 2008, Jamie Strandboge wrote:
I discovered that there is also 3rd key which you get if you pass empty
file by -rand. Keys created in this way are still the same so it's
another possible compromised key. I'm not sure if it worth spend time on
counting this keys...
On Mon, May 19, 2008 at 02:17:42PM +0200, Florian Weimer wrote:
* Kees Cook:
The rule is simple. When the ~/.rnd file doesn't exist I get one key and
in other situation I get another (that listed in Ubuntu
openssl-blacklist) key. Because of this problem openssl-blacklist has to
be
On May 21, 2008, at 12:06 PM, Bodo Moeller wrote:
A more elaborate explanation seems in place to make sure that
we avoid uninentionally incomplete blacklists.
..
I'd expect there to be some significant overlapping between the
blacklists, but these should still be different lists: Many RSA
On Monday 19 May 2008, Florian Weimer wrote:
BTW, it appears that the same blacklist can be used for -3 and -F4
keys. (Just in case you haven't checked that already.)
RSA keys with exponent 3 should probably not be used at all, because
multiple implementations did not verify the signatures
On Wed, May 21, 2008 at 2:46 PM, Dirk-Willem van Gulik
[EMAIL PROTECTED] wrote:
On May 21, 2008, at 12:06 PM, Bodo Moeller wrote:
A more elaborate explanation seems in place to make sure that
we avoid uninentionally incomplete blacklists.
I'd expect there to be some significant overlapping
On Mon, 19 May 2008, Jan Tomasek wrote:
Kees Cook wrote:
The rule is simple. When the ~/.rnd file doesn't exist I get one key
and in other situation I get another (that listed in Ubuntu
openssl-blacklist) key. Because of this problem openssl-blacklist has
to be twice big than
Jamie Strandboge wrote:
I discovered that there is also 3rd key which you get if you pass empty
file by -rand. Keys created in this way are still the same so it's
another possible compromised key. I'm not sure if it worth spend time on
counting this keys...
Empty files vs non-existent
On May 19, 2008, at 9:52 PM, Jan Tomasek Florian Weimer wrote:
I do not trust dowkd.pl script because
it lacks info where keys were taken.
...
We did not want to publish this information in order to give system.
Do bear in mind that the public key consists of 1) the modulus and 2)
the
* Kees Cook:
The rule is simple. When the ~/.rnd file doesn't exist I get one key and
in other situation I get another (that listed in Ubuntu
openssl-blacklist) key. Because of this problem openssl-blacklist has to
be twice big than openssh-blacklist. I developed simple shell scripts to
Kees Cook wrote:
The rule is simple. When the ~/.rnd file doesn't exist I get one key and
in other situation I get another (that listed in Ubuntu
openssl-blacklist) key. Because of this problem openssl-blacklist has to
be twice big than openssh-blacklist. I developed simple shell scripts to
On May 19, 2008, at 2:17 PM, Florian Weimer wrote:
The rule is simple. When the ~/.rnd file doesn't exist I get one
key and
in other situation I get another (that listed in Ubuntu
openssl-blacklist) key. Because of this problem openssl-blacklist
has to
be twice big than openssh-blacklist.
* Dirk-Willem van Gulik:
One way to do this a bit more careful may be by comparing the actual
data itself. OpenSSL will output this with the modulus flag:
openssl genrsa 1024 | openssl rsa -noout -modulus
Yes, that's what dowkd is doing (albeit with a somewhat suboptimal
algorithm; I
On Mon, May 19, 2008 at 02:24:01PM +0200, Jan Tomasek wrote:
What is your 3rd architecture? On Ubuntu pages I see only PC (Intel x86)
desktop CD and 64-bit PC (AMD64) desktop CD?
Sparc and PowerPC are big-endian with a 32-bit userspace. These exist
in Debian currently, and existed in Ubuntu
On May 19, 2008, at 2:54 PM, Florian Weimer wrote:
* Dirk-Willem van Gulik:
One way to do this a bit more careful may be by comparing the actual
data itself. OpenSSL will output this with the modulus flag:
openssl genrsa 1024 | openssl rsa -noout -modulus
Yes, that's what dowkd is
* Dirk-Willem van Gulik:
Working with the original and some indication as to what pid,
platform, keylen endianness, and .rnd, is useful - as that way it is
possible to understand, reconstruct, spotcheck or verify in-situ -
rather than having to build trust without easy verify.
It's also
On May 19, 2008, at 3:15 PM, Florian Weimer wrote:
* Dirk-Willem van Gulik:
Working with the original and some indication as to what pid,
platform, keylen endianness, and .rnd, is useful - as that way it is
possible to understand, reconstruct, spotcheck or verify in-situ -
rather than having
Dirk-Willem van Gulik wrote:
On May 19, 2008, at 3:15 PM, Florian Weimer wrote:
* Dirk-Willem van Gulik:
Working with the original and some indication as to what pid,
platform, keylen endianness, and .rnd, is useful - as that way it is
possible to understand, reconstruct, spotcheck or verify
* Jan Tomasek:
This is good argument. When I was trying to secure my systems from
weak SSH keys. I decided to use ssh-vulnkey and build blacklists by
myself from work of H D Moore. I do not trust dowkd.pl script because
it lacks info where keys were taken.
We did not want to publish this
Hello,
When this OpenSSL bug was announced our main interest at CESNET was to
warn users of our CA. We were thinking about using of keys published by
H D Moore hdm[at]metasploit.com at the page
http://metasploit.com/users/hdm/tools/debian-openssl/
My colleague developed script for
On Mon, May 19, 2008 at 01:09:25AM +0200, Jan Tomasek wrote:
My colleague developed script for converting X509 certificates to SSH
key hash. It was strange when we realized that none of issued
certificates matched. It is because OpenSSH and OpenSSL blacklist are
not compatible. OpenSSH
22 matches
Mail list logo
