On Mon, Oct 16, 2017 at 09:13:19PM +0200, Yves-Alexis Perez wrote:
> On Mon, 2017-10-16 at 21:06 +0200, Christian Seiler wrote:
> > Unfortunately, as far as I understand it, there's no easy method for
> > detecting these kinds of broken keys without actually attempting to
> > factorize them - and while that's feasible (hence the vulnerability)
> > it is still quite expensive - so there is currently no easy method of
> > scanning through the Debian keyring for affected keys.
>
> Actually that's wrong, the generation process leaves “fingerprints” which can
> be used to identify keys. See for example:
>
> https://keychest.net/roca
> https://github.com/crocs-muni/roca
>
> These tools have been used to identify three vulnerable (sub)keys in the
> Debian keyring (this is already been taken care of).
It's been quite frustrating to deal with all the well-meaning
individuals who have been making keyring-maint aware of this today. I
haven't had time to prepare a canned statement that would present, our
understanding of the issues, and there were a couple of things I wanted
to run by the rest of the team once I'd assessed the impact to the
keyring. That's meant multiple people trying to get into a conversation
about the issue on IRC, and several emails as well.
There are 3 Debian Developers with 6 subkeys in the current keyring
working tree that are flagged by the roca tool. These belong to jelmer,
olasd & siretart[0].
Firstly, none of the flagged keys is a master key, so there is a simple
resolution of revoking the broken subkeys and securely generating new
ones. The users in question can then send the updated keys via HKP to
keyring.debian.org (i.e. using "gpg --keyserver keyring.debian.org
--send-key") and they'll be picked up in the next keyring update.
Secondly, all of the flagged keys are 4096-bit. My reading of the
situation is that there is still a significant amount of effort required
to factorise these keys and that a knee-jerk removal from the keyring is
therefore overkill. After sending this mail I intend to contact the
affected developers directly and propose that they revoke their subkeys
within the next week, and that we'll do a keyring update at that point,
or sooner if we receive confirmation all have already done so.
J.
[0] I debated listing them here but it's easy enough to work it out and
I know at least one individual not associated with keyring-maint has
already emailed them.
--
"Why? - because it's f***ing there!" -- Edmund Hilary
Attachment:
signature.asc
Description: PGP signature