[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080518000655.GA9017@openwall.com>
Date: Sun, 18 May 2008 04:06:55 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: OpenSSH key blacklisting
On Sun, May 18, 2008 at 01:20:59AM +0200, Robert Buchholz wrote:
> let's focus on the blacklist:
...
> I like the Debian/Ubuntu idea of being able to add/remove blacklists
> easily.
Just how easy do we want to make this? Do we need this capability for
ourselves (package maintainers) or for end-users (sysadmins)? I'd
choose the former, and use maybe Perl scripts for the task. Those
scripts would be publicly available, such as via an URL posted to this
mailing list, but not made a part of any packages.
I find it undesirable to make this functionality directly available to
end-users. That's for several reasons:
1. We'd have to spend far more time on the blacklist update code,
perhaps programming it in C and making it extra-reliable (such as
detecting incorrect invocations and input files), as well as on
documentation for it.
2. Both pieces of code - the "updater" and the patch - would have to be
made more generic (e.g., work for a wide range of blacklist sizes) -
which might increase code size and complexity (e.g., we'd be tempted to
support arbitrary "prefix lengths", not just 12 bits).
3. How would an end-user add a key to our blacklist? Would we have to
support multiple blacklist files in the patch? Or would we include an
"uncompressor" program? Or would the user need to download either the
"source" blacklist or the "uncompressor" program? In the latter case,
the user could as well download our "encoder" script, and not fear its
dependency on Perl.
> Personally, I generated an incomplete (due to lack of hardware)
> set of keys for RSA 1024, 2048, 4096, and DSA 1024 keys, since that is
> what I have seen in the wild.
> It might be argued that since Sep. 2006, few people generated 1024 bit RSA
> keys, but I do not know exactly when "ssh-keygen"'s default was changed.
What matters is when the default in Debian's package was changed,
although it is possible that some users updated OpenSSL, but not
OpenSSH, which would result in vulnerable 1024-bit RSA keys.
Also, aren't protocol 1 keys 1024-bit RSA only, even with the latest
ssh-keygen?
Then, is it just one set of vulnerable 1024-bit RSA keys for both
protocols - or is it two sets?
> I'm putting Kees in CC since I hope he can help with the unshortened
> fingerprint list (at least via private mail).
I've dropped the explicit CC because Kees is subscribed.
Kees - please let us know if you'd like to be CC'ed on most relevant
postings. As to the fingerprint list, I'd appreciate it if you provide
separate lists for different key types, sizes, and archs - such that we
can produce any combinations. The "unshortened" aspect is not as
important; we'll probably pick last N bits of fingerprints anyway, to
allow for comparison between our blacklist and that in the Debian and
Ubuntu packages.
> Whoever changed his pid_max to another value, and generated the key after
> running some 33000 processes, would be both lucky (because his key is
> unlikeley to be in the attacker's keychain), and unlucky (since the key is
> not blacklisted). I see little point in supporting other than the default
> PIDs.
I agree.
Thanks,
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
