On 26 aug. 2011, at 13:22, linbloke wrote:
I'm curious as to why you suggest option 2 over option 1 from the Apache
advisory? My guess is that it is compatible with version 1.3 and 2.x and that
is has stronger enforcement of the syntax (by requiring ^bytes=) rather than
just 5 comma
On May 23, 2008, at 3:13 PM, Florian Weimer wrote:
* Dirk-Willem van Gulik:
Perhaps confusion over false negatives - as the current ring does not
include all endian/cpu flavours - it is possible (currently) for it
to
return no compromised keys - while there are in fact some.
Could
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 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
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.
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
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
On May 17, 2008, at 1:34 PM, Matteo Vescovi wrote:
are there updates for this issue for old stable - sarge?
It was said sarge is not affected,
Bear in mind that you still want blacklist support for the various
tools, not just for the known_hosts and authorized_keys; but also for
On May 17, 2008, at 2:23 PM, Florian Weimer wrote:
Someone has added a warning to the wiki page
http://wiki.debian.org/SSLkeys that dowdkd.pl produces many false
positives.
Even if there are bugs in the script, this is *very* unlikely. Could
someone please provide such an alleged false
Just FYI - there seems a minor fault in the openssl-blackist tool[1],
I strongly suspect that the line:
#print bits: %s\nmodulus: %s\nkey: %s\nkey80: %s % (bits,
modulus, key, key[20:])
if key[20:] in db_lines:
needs to be
key = sha.sha(modulus).hexdigest()
#print bits:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The diff below lets one not just check the private keys - but also
check the public part thereof. This is useful - as the latter can
also be obtained with:
openssl s_client -connect fqdn:443 -showcerts
or be ran over a store, say the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Just FYI - there seems a minor fault in the openssl-blackist tool[1],
I strongly suspect that the line:
#print bits: %s\nmodulus: %s\nkey: %s\nkey80: %s % (bits,
modulus, key, key[20:])
if key[20:] in db_lines:
needs to be
key =
On May 16, 2008, at 12:48 PM, Dirk-Willem van Gulik wrote:
Just FYI - there seems a minor fault in the openssl-blackist tool, I
strongly suspect
After discussing this with Jamie - two things - First note that above
is NOT the case
provided that you used [1] or more recent
13 matches
Mail list logo
