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