Re: State of the debian keyring
On 27/02/14 at 11:11 +0100, Yves-Alexis Perez wrote: On Mon, Feb 24, 2014 at 05:35:34PM +0100, Lucas Nussbaum wrote: Hi, On 22/02/14 at 20:57 -0500, Andrew Starr-Bochicchio wrote: Has there been any analysis of how active the developers are? I'd hazard to guess that a good number should be moved to emeritus status. Perhaps we should do a ping of developers with 1024 bit keys? I've done a quick hack using UDD: http://udd.debian.org/cgi-bin/gpg1024.cgi Nice public shaming :) A large number of people still using 1024 bit keys are very active DDs. Well, a quick grep on the result shows that of those 652 uploads done using 1024b keys, only half of them were made since the beginning of 2013. Not really, the listing is about keys, not uploads (only listing the last upload for a given key). The correct interpretation is: | Well, a quick grep on the result shows that of those 652 1024b keys, | only half of them were used for uploads since the beginning of 2013. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140228105204.ga21...@xanadu.blop.info
Re: State of the debian keyring
On Fri, Feb 28, 2014 at 11:52:04AM +0100, Lucas Nussbaum wrote:
Not really, the listing is about keys, not uploads (only listing the
last upload for a given key). The correct interpretation is:
| Well, a quick grep on the result shows that of those 652 1024b keys,
| only half of them were used for uploads since the beginning of 2013.
It doesn't really change anything, does it? Sure, uploads are not the
only way to check someone is active, but still, people with no upload
since 2012 and a 1024{D,R} key is likely a candidate for direct contact.
--
Yves-Alexis Perez
signature.asc
Description: Digital signature
Re: State of the debian keyring
On Fri, Feb 28, 2014 at 01:59:23PM +0100, Yves-Alexis Perez wrote:
It doesn't really change anything, does it? Sure, uploads are not the
only way to check someone is active, but still, people with no upload
since 2012 and a 1024{D,R} key is likely a candidate for direct contact.
It would probably be expected of me to point out that there is more to
contributing to Debian than just package uploads[1].
On the other hand, in my opinion even active people should be candidates
for direct contact[2], when they look like they're lagging behind what's
expected and announced to debian-devel-announce.
Ciao,
Enrico
[1] https://contributors.debian.org/sources/
[2] Especially helpful and polite direct contact, rather than direct
contact to the head with a knobby stick :)
--
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org
signature.asc
Description: Digital signature
Re: State of the debian keyring
On Mon, Feb 24, 2014 at 05:35:34PM +0100, Lucas Nussbaum wrote: Hi, On 22/02/14 at 20:57 -0500, Andrew Starr-Bochicchio wrote: Has there been any analysis of how active the developers are? I'd hazard to guess that a good number should be moved to emeritus status. Perhaps we should do a ping of developers with 1024 bit keys? I've done a quick hack using UDD: http://udd.debian.org/cgi-bin/gpg1024.cgi Nice public shaming :) A large number of people still using 1024 bit keys are very active DDs. Well, a quick grep on the result shows that of those 652 uploads done using 1024b keys, only half of them were made since the beginning of 2013. 327 have been done *before* 2013. I guess those can't really be treated as “active” and are candidate for emeritus or disable after a wat run. Regards, -- Yves-Alexis Perez signature.asc Description: Digital signature
Re: State of the debian keyring
On Tue, Feb 25, 2014 at 02:34:01AM +, Marco d'Itri wrote: enr...@enricozini.org wrote: It also took me a long while to switch because I didn't understand that it was already this urgent, Because unless you are paranoid, then it is not. If anybody disagrees then please describe a credible threat model in which: - an entity would want to have access to the key of a DD, and - would find brute forcing a 1024 bit key more practical than stealing it or coercing a developer to disclose it. There's also the hash algorithm issue, which could lead to signature collision attacks (wether in data signing or in key signing). Regards, -- Yves-Alexis Perez signature.asc Description: Digital signature
Re: State of the debian keyring
On Feb 27, Yves-Alexis Perez cor...@debian.org wrote: Because unless you are paranoid, then it is not. If anybody disagrees then please describe a credible threat model in which: - an entity would want to have access to the key of a DD, and - would find brute forcing a 1024 bit key more practical than stealing it or coercing a developer to disclose it. There's also the hash algorithm issue, which could lead to signature collision attacks (wether in data signing or in key signing). Please describe a credible threat model, etc. Theoretically possible also means that somebody could factor a RSA 4096 key at the first try with pen and paper so it does not matter much. -- ciao, Marco signature.asc Description: Digital signature
Re: State of the debian keyring
On 2014-02-27, Yves-Alexis Perez cor...@debian.org wrote: Well, a quick grep on the result shows that of those 652 uploads done using 1024b keys, only half of them were made since the beginning of 2013. 327 have been done *before* 2013. I guess those can't really be I'm unsure when I did my last upload, but I definitely consider myself active. But maybe I should figure out how to move to the 4096 key that I actually have collected a set of signatures on. /Sune -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/len6br$m79$1...@ger.gmane.org
Re: State of the debian keyring
Enrico Zini writes (Re: State of the debian keyring): ...which reminds me of http://www.enricozini.org/2008/tips/audit-uploads/ which was a prototype of creating an audit log of key usage in debian. ... This means hooking into any place where a signature verification or a decryption actually happens in Debian: I can think of uploads, db.debian.org, voting, keyring requests, RT tickets filed, emails received by lists or the BTS: are there more? My (not-yet-deployed) dgit push receiver (to support, amongst other things, dm uploads), which depends on tags signed by dm pgp keys. ssh push to alioth. (Sorry to add a very hairy yak to your plan.) dget. So I can't just open vim and write the code: auditing key usage in package uploads requires someone who knows dak inside out, and can commit to maintaining notification triggers in all obscure corners where keys are used, now and in future updates of the ftp-master toolchain. Same goes for any other bit of Debian. Perhaps we could provide a patched version of gpg[v] which phones home to report the verification. The starting point for this work is probably this, then: is it just me, feeling that we have a problem here, or am I actually in the good company of people who can do their bit? I think this would be nice, and having a partial audit would be better than no audit. Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21263.12362.656891.831...@chiark.greenend.org.uk
Re: State of the debian keyring
Jonathan McDowell writes (Re: State of the debian keyring): On Mon, Feb 24, 2014 at 05:53:58PM +, Ian Jackson wrote: Are we now at the stage where it is more important to retire these shortish keys, than to insist on this cross-signatures ? ... I'd rather avoid this if possible, but it's something I'd be prepared to consider for those who really can't manage to any another signature. So you have answered my question with no. In conclude that this weak keys problem is not all that urgent, in your opinion. I'll stop worrying about it too much. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21263.15170.799801.189...@chiark.greenend.org.uk
Re: State of the debian keyring
On Thu, Feb 27, 2014 at 11:19:23AM +0100, Marco d'Itri wrote: On Feb 27, Yves-Alexis Perez cor...@debian.org wrote: Because unless you are paranoid, then it is not. If anybody disagrees then please describe a credible threat model in which: - an entity would want to have access to the key of a DD, and - would find brute forcing a 1024 bit key more practical than stealing it or coercing a developer to disclose it. There's also the hash algorithm issue, which could lead to signature collision attacks (wether in data signing or in key signing). Please describe a credible threat model, etc. Theoretically possible also means that somebody could factor a RSA 4096 key at the first try with pen and paper so it does not matter much. I'm not concerned about the hash algorithm myself. As I understand it, it's a preimage attack. MD5 is broken for that in that it can be done in 2^123 instead of 2^128, and so should still be fine. SHA1 is still at 2^160, and so such clearly not a problem. SHA1 on the other hand is at 2^60 for a collision attack. That is, someone could generate 2 keys with the same fingerprint in a reasonable time, but can not generate a key with the same fingerprint as an existing key. The current cost estimate for such a collision attack is around 1M USD. See: https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html MD5 is currently completly useless if collision resistance is important, it's around 2^18, and in the other of seconds. But as far as I know, for most cases we don't care about collision resistance, but do care about the preimage resistance. As long as you're not singing something that an attacker has control over MD5 and SHA1 should still be safe. If an attacker does have control over it, SHA-2 would be safe instead. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140227192851.ga30...@roeckx.be
Re: State of the debian keyring
On Thu, Feb 27, 2014 at 01:18:58PM +, Ian Jackson wrote: Jonathan McDowell writes (Re: State of the debian keyring): On Mon, Feb 24, 2014 at 05:53:58PM +, Ian Jackson wrote: Are we now at the stage where it is more important to retire these shortish keys, than to insist on this cross-signatures ? ... I'd rather avoid this if possible, but it's something I'd be prepared to consider for those who really can't manage to any another signature. So you have answered my question with no. Actually, that's not what he replied. You asked wether to chose between Scylla and Charybdis, and Jonathan just replied that Charybdis wasn't a really good option but would there be no other choice, in specific situation, he'd be prepared to do that. That's very different than “no”. In conclude that this weak keys problem is not all that urgent, in your opinion. I'll stop worrying about it too much. *sighs* Considering you already have a 2048R master key, sure, you can stop worrying for now (I'm unsure why you chose not to directly have a 4096R one, but eh). That won't actually stop me worrying for the rest of the Debian keyring, because only one compromised key is enough, and cryptography is really a field where you prefer to be safe than sorry. Regards, -- Yves-Alexis Perez signature.asc Description: Digital signature
Re: State of the debian keyring
On Thu, Feb 27, 2014 at 11:08:43AM +, Sune Vuorela wrote: On 2014-02-27, Yves-Alexis Perez cor...@debian.org wrote: Well, a quick grep on the result shows that of those 652 uploads done using 1024b keys, only half of them were made since the beginning of 2013. 327 have been done *before* 2013. I guess those can't really be I'm unsure when I did my last upload, but I definitely consider myself active. 2013-07-14T19:00:07+00:00 5CE8ADFA1FDD9DEA6E21DCE19CCBDA1601FA8B4A Sune Vuorela (kdevplatform) But maybe I should figure out how to move to the 4096 key that I actually have collected a set of signatures on. Sure, please go ahead :) -- Yves-Alexis Perez signature.asc Description: Digital signature
Re: State of the debian keyring
Gunnar Wolf writes (Re: State of the debian keyring): Debian tools don't care which key you use for email encryption. The extent of actions you interact with debian is easily modeled with a single key; for some time I used to upload with 1024D and sign mails with 4096R because I had not yet pushed my 4096R into the keyring, waiting to get more signatures (yes, also being keyring-maint it took me some time to push it, even if I had all power to do so myself!) Except, the requirement to get your keys signed by two DDs means that you can't just get the DDs to sign a master certification key. (Nowadays you can do this with subkeys, but.) Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21261.44335.199913.686...@chiark.greenend.org.uk
Re: State of the debian keyring
On Mon, Feb 24, 2014 at 06:51:37PM -0800, Russ Allbery wrote: Brute-forcing the key just requires compute cycles. There is essentially no chance of discovery and no risky activity at all until you start actually using the key. ...which reminds me of http://www.enricozini.org/2008/tips/audit-uploads/ which was a prototype of creating an audit log of key usage in debian. However, for the audit log to be usable as an audit log without giving a false sense of security, it should be complete, and really cover all instances of key usage in Debian. This means hooking into any place where a signature verification or a decryption actually happens in Debian: I can think of uploads, db.debian.org, voting, keyring requests, RT tickets filed, emails received by lists or the BTS: are there more? I see the job as not so much technically complex[1] as socially complex: since I would not trust auditing an incomplete audit log, I fear that a missing or badly implemented data source could invalidate all the system. So I can't just open vim and write the code: auditing key usage in package uploads requires someone who knows dak inside out, and can commit to maintaining notification triggers in all obscure corners where keys are used, now and in future updates of the ftp-master toolchain. Same goes for any other bit of Debian. The starting point for this work is probably this, then: is it just me, feeling that we have a problem here, or am I actually in the good company of people who can do their bit? Ciao, Enrico [1] For realtime auditing, we now have a rabbitmq server. Or collection could be decoupled in one audit log per team, which are then aggregated by a separate project. Or they can be submitted to a central collection point, like a new ad-hoc bit of contributors.debian.org. I don't see anything technically difficult here. -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: State of the debian keyring
On Tue, Feb 25, 2014 at 5:47 PM, Enrico Zini wrote: This means hooking into any place where a signature verification or a decryption actually happens in Debian: I can think of uploads, db.debian.org, voting, keyring requests, RT tickets filed, emails received by lists or the BTS: are there more? I didn't think the BTS cared about OpenPGP keys? mentors.d.n does do signature verification of uploads. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6HH4ZfhGyUX3BxuXx7f1w=f9qbrx9uo_enhslct5u0...@mail.gmail.com
Re: State of the debian keyring
Ian Jackson dijo [Mon, Feb 24, 2014 at 05:53:58PM +]:
Are we now at the stage where it is more important to retire these
shortish keys, than to insist on this cross-signatures ?
I.e., perhaps it would be better to invite key rollover from a short
key to a long one despite the lack of 2 other DD signatures; or
perhaps even despite the lack of _any_ other DD signatures.
Instead, the keyholder could perhaps present a signed key transition
document.
A downside is that we would probably have to keep the rolled-over
short keys somewhere, at least to maintain the integrity of our
records of why a key is in the keyring.
Which we do anyway - All retired keys are still in our tree, in the
removed-keys-{pgp,gpg} directories (plus the
emeritys-keyring-{gpg,pgp}). Of course, they are not installed when
you get the generated package (you only get the active keyrings). But
they are all there.
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140225184458.gh40...@gwolf.org
Re: State of the debian keyring
Ian Jackson dijo [Mon, Feb 24, 2014 at 05:57:57PM +]: I think this is a bug. It can increase security because it can make operations more convenient at the same level of security, and because people trade off convenience for security. For example, it would be possible to have one key for email encryption and a different (more secure) key for package uploads. Debian tools don't care which key you use for email encryption. The extent of actions you interact with debian is easily modeled with a single key; for some time I used to upload with 1024D and sign mails with 4096R because I had not yet pushed my 4096R into the keyring, waiting to get more signatures (yes, also being keyring-maint it took me some time to push it, even if I had all power to do so myself!) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140225184724.gi40...@gwolf.org
Re: State of the debian keyring
Gunnar Wolf gw...@gwolf.org writes: Ian Jackson dijo [Mon, Feb 24, 2014 at 05:57:57PM +]: I think this is a bug. It can increase security because it can make operations more convenient at the same level of security, and because people trade off convenience for security. For example, it would be possible to have one key for email encryption and a different (more secure) key for package uploads. Debian tools don't care which key you use for email encryption. Except for project DPL votes, no? The extent of actions you interact with debian is easily modeled with a single key; for some time I used to upload with 1024D and sign mails with 4096R because I had not yet pushed my 4096R into the keyring, waiting to get more signatures (yes, also being keyring-maint it took me some time to push it, even if I had all power to do so myself!) For email signatures, don't quite a few more things care? All votes, db.debian.org operations, etc. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ios3auur@windlord.stanford.edu
Re: State of the debian keyring
On Tue, 25 Feb 2014, Paul Wise wrote: I didn't think the BTS cared about OpenPGP keys? We probably will eventually, but we only use[1] them now to help whitelist mail. 1: By which I mean that if a message seems to have a PGP signature, we think it's probably not spam; we currently don't even bother to check it. -- Don Armstrong http://www.donarmstrong.com Of course, there are cases where only a rare individual will have the vision to perceive a system which governs many people's lives; a system which had never before even been recognized as a system; then such people often devote their lives to convincing other people that the system really is there and that it aught to be exited from. -- Douglas R. Hofstadter _Gödel Escher Bach. Eternal Golden Braid_ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140225190806.gc10...@teltox.donarmstrong.com
Re: State of the debian keyring
On Tue, Feb 25, 2014 at 10:51:56AM -0800, Russ Allbery wrote: Gunnar Wolf gw...@gwolf.org writes: Ian Jackson dijo [Mon, Feb 24, 2014 at 05:57:57PM +]: I think this is a bug. It can increase security because it can make operations more convenient at the same level of security, and because people trade off convenience for security. For example, it would be possible to have one key for email encryption and a different (more secure) key for package uploads. Debian tools don't care which key you use for email encryption. Except for project DPL votes, no? I think the keys are used for voting and the email interfance for db.debian.org. I'm not sure if we have any other services checking the gpg signatures of emails. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140225201000.ga5...@roeckx.be
Re: State of the debian keyring
On Tue, Feb 25, 2014 at 10:51:56AM -0800, Russ Allbery wrote: Gunnar Wolf gw...@gwolf.org writes: Ian Jackson dijo [Mon, Feb 24, 2014 at 05:57:57PM +]: I think this is a bug. It can increase security because it can make operations more convenient at the same level of security, and because people trade off convenience for security. For example, it would be possible to have one key for email encryption and a different (more secure) key for package uploads. ... For email signatures, don't quite a few more things care? All votes, db.debian.org operations, etc. More relevantly an email signature isn't any different to a signature for a package upload, so DDs would have to specify what the use for each key was, keyring-maint would have to maintain appropriate keyrings indicating what the expected use of a key was, and all the project facilities that make use of signatures would have to make decisions about which keyring they were using. (Yes, for encryption that's a different situation but the only example I can think of where the project uses encryption to a key in the keyring at present is the initial account password / a password reset. And for an encryption/signing split subkeys should be able to handle the desired outcome, I think.) J. -- xmpp:nood...@earth.li Time is an illusion. Lunchtime doubly so. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140225201243.go27...@earth.li
Re: State of the debian keyring
On Tue, Feb 25, 2014 at 09:10:00PM +0100, Kurt Roeckx wrote: On Tue, Feb 25, 2014 at 10:51:56AM -0800, Russ Allbery wrote: Gunnar Wolf gw...@gwolf.org writes: Ian Jackson dijo [Mon, Feb 24, 2014 at 05:57:57PM +]: I think this is a bug. It can increase security because it can make operations more convenient at the same level of security, and because people trade off convenience for security. For example, it would be possible to have one key for email encryption and a different (more secure) key for package uploads. Debian tools don't care which key you use for email encryption. Except for project DPL votes, no? I think the keys are used for voting and the email interfance for db.debian.org. I'm not sure if we have any other services checking the gpg signatures of emails. echelon checks the keyring, also. -- Luca Filipozzi http://www.crowdrise.com/SupportDebian signature.asc Description: Digital signature
Re: State of the debian keyring
Hi, On 22/02/14 at 20:57 -0500, Andrew Starr-Bochicchio wrote: Has there been any analysis of how active the developers are? I'd hazard to guess that a good number should be moved to emeritus status. Perhaps we should do a ping of developers with 1024 bit keys? I've done a quick hack using UDD: http://udd.debian.org/cgi-bin/gpg1024.cgi A large number of people still using 1024 bit keys are very active DDs. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140224163534.ga19...@xanadu.blop.info
Re: State of the debian keyring
Jonathan McDowell writes (Re: State of the debian keyring): On Sun, Feb 23, 2014 at 02:10:12PM +0800, Paul Wise wrote: * The new key must be signed by the old key that is being replaced. * The new key must be signed by 2 other keys that are present in the Debian keyring. Are we now at the stage where it is more important to retire these shortish keys, than to insist on this cross-signatures ? I.e., perhaps it would be better to invite key rollover from a short key to a long one despite the lack of 2 other DD signatures; or perhaps even despite the lack of _any_ other DD signatures. Instead, the keyholder could perhaps present a signed key transition document. A downside is that we would probably have to keep the rolled-over short keys somewhere, at least to maintain the integrity of our records of why a key is in the keyring. Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21259.34614.519800.702...@chiark.greenend.org.uk
Re: State of the debian keyring
Gunnar Wolf writes (Re: State of the debian keyring): Our tools (and I don't only mean keyring-maint, but our projectwide tools) support only one key per person. And frankly, I do not see a case where adding a second one would increase security. Yes, it could make the transition a little bit easier, but I don't think it is a change we should push. (Or maybe I misunderstood your suggestion). I think this is a bug. It can increase security because it can make operations more convenient at the same level of security, and because people trade off convenience for security. For example, it would be possible to have one key for email encryption and a different (more secure) key for package uploads. Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/21259.34853.289374.378...@chiark.greenend.org.uk
Re: State of the debian keyring
On Mon, Feb 24, 2014 at 11:35 AM, Lucas Nussbaum lu...@debian.org wrote: Hi, On 22/02/14 at 20:57 -0500, Andrew Starr-Bochicchio wrote: Has there been any analysis of how active the developers are? I'd hazard to guess that a good number should be moved to emeritus status. Perhaps we should do a ping of developers with 1024 bit keys? I've done a quick hack using UDD: http://udd.debian.org/cgi-bin/gpg1024.cgi A large number of people still using 1024 bit keys are very active DDs. I believe I have an idea that's better than the status quo, and is actionable now without potentially crippling the project. Please let me know if I am missing something significant. Perhaps we could create a new transition role GPG identity, that would be administered by the keyring maintainers and would sign any requests for changing to a strong key that are signed by the same DD's weak key. We would allow DDs to use the new strong key to do their work for a limited period of time, while they seek the required two DD signatures. (Say 12 months, but this is fungible.) I am proposing a role key, so it doesn't get confused with real sigs and we can easily track who still needs real sigs. Obviously as DDs switched to srong keys using this option, their old 1024 bit keys would be disabled, but to really make this better than the status quo, we would need to couple this with a policy to set a fairly aggressive date for disabling any 1024 bit keys. (Basically just enough time for keyring maintainers to absorb the influx of key change requests from active DDs.) This prevents us from having to wait for everyone to get their 2 sigs to move to stronger security. It also means we can as a project set a relatively aggressive date of turning off 1024-bit keys. The biggest drawback I foresee is that this does put a large burst of workload on the keyring maintainers. (I suspect however this shouldn't be a showstopper, as we could make approval contingent on having enough extra volunteers to implement it.) Thanks, Brian P.S. - We could even give a certain grace period, after disabling 1024 bit keys, to allow DDs to use the same process if they someone missed the announcements and get stuck being unable to upload. (This way we can be even more aggressive about turning off the 1024bit keys.) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CACFaiRzr6y5=9_pd+xngyhdrkrbyorprjgphf_-c6ody-x5...@mail.gmail.com
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 05:46:53PM +0300, Cyril Brulebois wrote: (It took me like 4 years to switch to my current 4k key, partly because I didn't feel the urge to switch, and partly because I would have hated wasting your time with a malformed request.) It also took me a long while to switch because I didn't understand that it was already this urgent, so my mode of operation was let's collect sigs for the time being, and switch when I hear another call. I think it would be useful to see an update to debian-devel-announce, explaining what's the current vulnerability status of 1024bit keys, and asking to please switch NOW. As a potential follow-up plan, I propose this one: After a month or two, we can start mailing people directly, starting from the most active, asking why they haven't migrated yet, and asking them to please tell others to migrate if they see a 1024 key around. After another month or two, we can start taking keys off the keyring, starting from the less active people, and announcing each batch of removed keys to d-d-a. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: State of the debian keyring
On Mon, 24 Feb 2014, Ian Jackson wrote: It can increase security because it can make operations more convenient at the same level of security, and because people trade off convenience for security. For example, it would be possible to have one key for email encryption and a different (more secure) key for package uploads. This is already possible with subkeys. That said subkeys of a 1024 bits master key can't really be trusted, even if they are bigger. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140224193700.ga15...@x230-buxy.home.ouaza.com
Re: State of the debian keyring
On Mon, Feb 24, 2014 at 08:28:53PM +0100, Enrico Zini wrote: I think it would be useful to see an update to debian-devel-announce, explaining what's the current vulnerability status of 1024bit keys, and asking to please switch NOW. As a potential follow-up plan, I propose this one: Seconded. If I'm reading Clint's reports right, the aspect that worries me the most is that in 1 month (the delay between the two reports) we've only got 10 additional 4K keys, which is a very slow progress rate. I agree with Enrico that the next step is communicating clearly to project members the *urge* of switching, and I also agree that we should actively nag people to do the switch. Regarding the doc on the migration, I don't have clear proposals on how to make it better, but I AOL other comments in this thread: I've been misreading the text myself for quite a while (or maybe it did change and I didn't notice? no idea) as mandating a third-party to request the change. And I've been chatting with various DDs over time who were postponing the change due to that extra step --- yes, I agree that's a silly reason, but given the urge of migrating I think we should make the procedure as simple as possible and make sure that people *know* it is simple. Just my 0.02 EUR, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: State of the debian keyring
On Mon, Feb 24, 2014 at 05:53:58PM +, Ian Jackson wrote: Jonathan McDowell writes (Re: State of the debian keyring): On Sun, Feb 23, 2014 at 02:10:12PM +0800, Paul Wise wrote: * The new key must be signed by the old key that is being replaced. * The new key must be signed by 2 other keys that are present in the Debian keyring. Are we now at the stage where it is more important to retire these shortish keys, than to insist on this cross-signatures ? I.e., perhaps it would be better to invite key rollover from a short key to a long one despite the lack of 2 other DD signatures; or perhaps even despite the lack of _any_ other DD signatures. Instead, the keyholder could perhaps present a signed key transition document. I'd rather avoid this if possible, but it's something I'd be prepared to consider for those who really can't manage to any another signature. There's also the halfway house of allowing keys which are in the global strong set, even if they're not signed by other keys within the Debian strong set. At present I don't think we're yet at the stage we have to allow this though. A downside is that we would probably have to keep the rolled-over short keys somewhere, at least to maintain the integrity of our records of why a key is in the keyring. One of the useful things about the fact the keyring is managed in bzr[0] these days is that the changelog can record why something is the way it is. J. [0] At some point it will probably move to git, it's in bzr for historical reasons. -- Web [ 101 things you can't have too much of : 21 - Uptime. ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140224204048.gf27...@earth.li
Re: State of the debian keyring
Hi, Brian Gupta: weak key. We would allow DDs to use the new strong key to do their work for a limited period of time, while they seek the required two DD signatures. (Say 12 months, but this is fungible.) I am proposing a role key, so it doesn't get confused with real sigs and we can easily track who still needs real sigs. OK, so except for the use a role key for tracking part this is exactly what I proposed, or attempted to propose anyway, in my last email. I don't think we'd need a separate role key, that'd require two key transitions per DD and thus more work for the keyring maintainers. A list of strong keys in the keyring as of now should be sufficent. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: State of the debian keyring
Marco d'Itri m...@linux.it writes: If anybody disagrees then please describe a credible threat model in which: - an entity would want to have access to the key of a DD, and - would find brute forcing a 1024 bit key more practical than stealing it or coercing a developer to disclose it. Brute-forcing the key just requires compute cycles. There is essentially no chance of discovery and no risky activity at all until you start actually using the key. You can basically choose exactly how or when you want to use it, or use it only passively to decrypt data (although we don't really use our keys much for encryption, mostly). Stealing the key or coercing a developer is *far* riskier and runs a far higher chance of discovery, because both necessarily involve doing things out in the world that are visible and noticable and that would be of potential interest to the news media, etc. The reason why people tend to focus on passive risks like brute-force factoring is that they're only difficult in terms of necessary compute power (or breakthrough mathematics). They pose essentially zero operational difficulty and essentially zero risk; all the data that you need to make the attempt is completely public, and attempting it is not at all suspicious. There's no risk of getting caught. That makes the attack far more feasible. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sir7lxae@windlord.stanford.edu
Re: State of the debian keyring
On Mon, 24 Feb 2014, Ian Jackson wrote: Gunnar Wolf writes (Re: State of the debian keyring): Our tools (and I don't only mean keyring-maint, but our projectwide tools) support only one key per person. And frankly, I do not see a case where adding a second one would increase security. Yes, it could make the transition a little bit easier, but I don't think it is a change we should push. (Or maybe I misunderstood your suggestion). I think this is a bug. I'm also not convinced it's actually correct. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140225061442.gt24...@anguilla.noreply.org
Re: State of the debian keyring
gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. (Also, my keyring update request has been waiting for 3 weeks now to be processed.) -- ciao, Marco -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/lec9ll$hlh$1...@posted-at.bofh.it
Re: State of the debian keyring
On Sat, Feb 22, 2014 at 06:35:06PM -0600, Gunnar Wolf wrote: Kurt Roeckx dijo [Sun, Feb 23, 2014 at 12:46:41AM +0100]: For those people who are not aware of this yet, this is really a problem. I agree. We should take security in Debian seriously. Getting weak keys replaced by strong ones in the keyring in time, keeping up with increasing computer power, is part of that. This provides less security than an 80 bit symmetric cipher. A brute force for this is possible. It's considered to have very short time protection against agencies, short time against medium organisations. That's still 61.5% that's at 1024 bit. CAs are doing better than this, with only 0.8% of the certificates that are still active being 1024 bit. Can I suggest that everyone that is still using a 1024 bit pgp key generates a new key *now*? Yes please, *now*. The recommended minimum size is at least 2048 bit, but I suggest you go for 4096 bit. ...And now hat you mention this here on the list, we have been discussing how to deal with this for keyring-maint¹. It would clearly be unacceptable for us to decide to lock out 61.5% of Debian because of their old key. In my opinion it would clearly be unacceptable for us to allow the weak keys in the keyring for a day longer. How about removing them now. Also, removing those keys would most probably make our WoT much more fragile. The WoT is already fragile due to the weak keys. Also, removing the weak keys from the keyring doesn't weaken the WoT because all keys still exist in public. I'd like to ask the project as a whole for input on how we should push towards this migration. I guess that most of the socially-connected Debian Developers already have 4096R keys. How can we reach those who don't? Contacting them can obviously be done via e-mail. Note that if they are still active DDs they should already be aware of the weakness of the keys. Let's get real on this, see the age of this message [0], a message all DDs should have read at the time. I understand however practical challenges for DDs living in remote areas for getting keys signed. [0] : https://lists.debian.org/debian-devel-announce/2010/09/msg3.html How can we incentivate them to change? As I wrote above, by removing the weak keys now. Remember that, in order to get a new key accepted, a big hurdle is sometimes the need for meeting two people with active keys. Several people have started the process to update their keys, but after months (and no real possibility to meet a DD in person) have let it stay as it is. This hurdle is, of course, very important to maintain in order to avoid loosening our identity requirements... So, what do you suggest? DDs with strong keys can help the locked out DDs with key signing [1] and with temporarily sponsoring important/urgent packages uploads [2]. I'm hereby offering this help myself now. [1] : https://wiki.debian.org/Keysigning/Offers [2] : http://mentors.debian.net/intro-maintainers Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223080943.ga11...@master.debian.org
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 07:57:43AM +, Marco d'Itri wrote: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. No, because this would reduce the value of the new keys to the weakness of the 1024 bit keys. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223081228.ga1...@master.debian.org
Re: State of the debian keyring
Hi, Bart Martens: On Sun, Feb 23, 2014 at 07:57:43AM +, Marco d'Itri wrote: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. No, because this would reduce the value of the new keys to the weakness of the 1024 bit keys. That's somewhat true for now given a sufficiently-motivated attacker, but if *afterwards* some nefarious $CENSORED gets the idea that $DD would be a nice target for hacking their key, they'd be out of luck. They'd also be out of luck if the DD's new key happens to already exist (which the DD who's asked to sign the new key should obviously check). Thus I would add the new key provisionally; if it doesn't get any new signatures from DDs with non-provisional strong keys during, say, the rest of this year, then delete it from the keyring. This would still be more secure than waiting a year before disabling the old keys, and come 2015 there would be no difference. However, I see another problem. http://keyring.debian.org/replacing_keys.html states that, if Alice wants to get her key X replaced with key Y, Alice must get a Debian developer […] to sign a message requesting the replacement of key X with key Y on behalf of Alice … which IMHO is an unnecessary burden if Alice's old and new key are valid and sufficiently DD-signed. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 10:23:47AM +0100, Matthias Urlichs wrote: Hi, Bart Martens: On Sun, Feb 23, 2014 at 07:57:43AM +, Marco d'Itri wrote: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. No, because this would reduce the value of the new keys to the weakness of the 1024 bit keys. That's somewhat true for now given a sufficiently-motivated attacker, but if *afterwards* some nefarious $CENSORED gets the idea that $DD would be a nice target for hacking their key, they'd be out of luck. They'd also be out of luck if the DD's new key happens to already exist (which the DD who's asked to sign the new key should obviously check). We don't know which 1024 bit keys may already have been compromised, so you would not know which new keys would be compromised as well. Thus I would add the new key provisionally; I don't see the point in provisionally adding potentially compromised keys. if it doesn't get any new signatures from DDs with non-provisional strong keys during, say, the rest of this year, then delete it from the keyring. I see no reason to allow more time, since we have been talking about 4096 keys since 2010. This would still be more secure than waiting a year before disabling the old keys, and come 2015 there would be no difference. A 4096 bit key is cryptographically stronger than a 1024 bit key, but the point of key signing is about verifying who is holding the private key. However, I see another problem. http://keyring.debian.org/replacing_keys.html states that, if Alice wants to get her key X replaced with key Y, Alice must get a Debian developer […] to sign a message requesting the replacement of key X with key Y on behalf of Alice … which IMHO is an unnecessary burden if Alice's old and new key are valid and sufficiently DD-signed. I suggest to discuss that in a separate thread. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223095620.ga16...@master.debian.org
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 07:57:43AM +, Marco d'Itri wrote: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. I'm not sure what you're saying, but I think it's a bad idea. What I would find acceptable is that if you generate an new key you sign the same keys with the new key that you signed previously with the old key. I would also find it acceptable that the keyring maintainers accept a signature from a single DD to replace the key, with that single DD being the DD's old key. If they old key doesn't get revoked there is still a (weak) web of trust. But I would like to see a signature from at least one other person with a stronger key that has a reasonable connection to the web of trust, preferably a DD. The more then better of course. I see no good reason to sign new keys without meeting the person to confirm that that is their new key. You seem to suggest that that is a good idea to keep the web of trust, but to me it seems you just create a web of trust that isn't really there. What we need is a way to confirm that you're talking to the same person you've met previously and confirm that that is his new key. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223112858.ga13...@roeckx.be
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 02:10:12PM +0800, Paul Wise wrote: On Sun, Feb 23, 2014 at 8:35 AM, Gunnar Wolf wrote: So, what do you suggest? Set a deadline (say 1 year?) for removal of all 1024 bit keys from the keyring. Notify all users of 1024 bit keys via all addresses listed in the MIA db and all UIDs on those keys. Remind people that coming to DebConf is a great way to get signatures. Talk to the DPL about spending Debian funds to help push this along. At the deadline, move all Debian members still using 1024 bit keys who responded to emeritus status and everyone else to disabled. I have been meaning to sit down a write a proposal for the removal of our weaker keys, and run it by Gunnar and Daniel before wider distribution. Part of my reticence is the knowledge that we're going to have to do 600 key replacements and it probably works out to at least 5 minutes per key change. Which is at least 50 hours of work, assuming the requests are all well formed and we don't need to go repeating ourselves about how to submit key change requests. In an attempt to try and reduce problems let me describe some of the problems we see (all of this is in the context of someone taking an existing key that is not believed to be compromised and replacing it with a stronger key): * Requests must be inline signed (gpg --clearsign). Unfortunately RT will mangle PGP/MIME signatures which means we can't verify them. (it will also decide to re-encode email in utf-8, which causes issues for people with non ASCII characters in their .sigs or names, but this is a much less frequent issue) * Requests need to include the full fingerprint of both the old and the new key. Not just the key IDs. Not just the new key. We want to be absolutely certain of what you're requesting replaced. I quite like seeing the actual gpg --fingerprint output for both keys because it tends to be quite easy to visually verify. * The new key must be signed by the old key that is being replaced. * The new key must be signed by 2 other keys that are present in the Debian keyring. * The request must be signed by the old key. Signing the request with the new key alone is not helpful - requests must always be signed by a key that is currently in the active keyring. Signing it with both is fine, but not required. * You should specify *why* you want to replace your key. Knowing that it's because you're moving to a stronger key rather than because your old key is compromised / unavailable / on fire helps us prioritise things. The time frame I'd had in mind was 6 months until we disable 1024 bit keys in the keyring, then perhaps a 3 month grace where we'll allow change requests to be signed by those disabled keys, then treat them as completely untrusted. At this point that would mean that post DebConf we'd do the disabling, and then by the end of the year we'd be 1024 bit free. I know that there are various people who have held off on submitting updated keys until they get more signatures. I believe I've already said it elsewhere, but at this point if you have 2 signatures from other DD keys on your new key you should be sending a request for replacement to keyr...@rt.debian.org (with something like Debian RT - Key replacement request for debianusername in the subject) following the above guidelines. J. -- xmpp:nood...@earth.li Most people are descended from apes. Redheads are descended from cats. signature.asc Description: Digital signature
Re: State of the debian keyring
Jakub Wilk dijo [Sun, Feb 23, 2014 at 02:29:22AM +0100]: It would clearly be unacceptable for us to decide to lock out 61.5% of Debian because of their old key. Also, removing those keys would most probably make our WoT much more fragile. I'd like to ask the project as a whole for input on how we should push towards this migration. A few of 1024 keys have been expired for more than a year. I bet more of them are unused. Perhaps a WAT run would help a bit? Important data point we should not let go. I'm opening a RT ticket so we as keyring-maint look more into this and take action. Thanks! -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223144054.ga32...@gwolf.org
Re: State of the debian keyring
Marco d'Itri dijo [Sun, Feb 23, 2014 at 07:57:43AM +]: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. I'm open to that if and only if the new keys have proper transition statements. And if the original signatures were *really* done carefully - Case in point, I took part of (too?) many massive key signing parties with my old 8BB527AF (1024D) key. Particularly, the DC5 to DC7 parties were mind-numbingly long, and the DC6 one was where Martin Krafft lit an interesting and important flame by *proving* most of use were not careful enough when checking identity papers. Since my key transition to 4096R, I only sign to people I can personally identify. And even so, I am certain several of the keys I signed in 2009/2010 were to people I would probably not recognize today (my face-to-name retention is quite deffective). So, no, I don't usually sign keys even where transition documents ask me to do so. (Also, my keyring update request has been waiting for 3 weeks now to be processed.) Right. We (keyring-maint) usually work by batching requests and spending some consecutive time on them. Our usual timeframe is once a month, and it is due this next week. So, don't feel forgotten, we will act on your request. signature.asc Description: Digital signature
Re: State of the debian keyring
Matthias Urlichs dijo [Sun, Feb 23, 2014 at 10:23:47AM +0100]: That's somewhat true for now given a sufficiently-motivated attacker, but if *afterwards* some nefarious $CENSORED gets the idea that $DD would be a nice target for hacking their key, they'd be out of luck. They'd also be out of luck if the DD's new key happens to already exist (which the DD who's asked to sign the new key should obviously check). Thus I would add the new key provisionally; if it doesn't get any new signatures from DDs with non-provisional strong keys during, say, the rest of this year, then delete it from the keyring. Our tools (and I don't only mean keyring-maint, but our projectwide tools) support only one key per person. And frankly, I do not see a case where adding a second one would increase security. Yes, it could make the transition a little bit easier, but I don't think it is a change we should push. (Or maybe I misunderstood your suggestion). However, I see another problem. http://keyring.debian.org/replacing_keys.html states that, if Alice wants to get her key X replaced with key Y, Alice must get a Debian developer […] to sign a message requesting the replacement of key X with key Y on behalf of Alice … which IMHO is an unnecessary burden if Alice's old and new key are valid and sufficiently DD-signed. Well, it is a hurdle, but not an insurmountable one. If you have an active, valid key, you can just sign with your own key and get a new one in the keyring, as long as it has at least two DD signatures. That assures us your computer was not h4x0red in order to steal your identity and lock you out. Say, in this (usual) case, you and Alice can be the same party. Now, if you lost control of your key (say, stolen computer), as soon as we get notice, we will retire your key (and that's not subject to our usual one month cycle as I told Marco for a *regular* key replacement). In order to get your key signed, we need an already-authenticated Alice (an Alice with her key in the keyring) to produce the request. The new key must, of course, meet our standards — Must have two DD signatures on it. Note that it does *not* require Alice's signature to be on it. signature.asc Description: Digital signature
Re: State of the debian keyring
Kurt Roeckx dijo [Sun, Feb 23, 2014 at 12:28:58PM +0100]: (...) I would also find it acceptable that the keyring maintainers accept a signature from a single DD to replace the key, with that single DD being the DD's old key. If they old key doesn't get revoked there is still a (weak) web of trust. But I would like to see a signature from at least one other person with a stronger key that has a reasonable connection to the web of trust, preferably a DD. The more then better of course. We have done this as an exception at some particular cases. But clearly treating it as an exception, not as the usual way to work. signature.asc Description: Digital signature
Re: State of the debian keyring
On Sun, 23 Feb 2014, Jonathan McDowell wrote: * Requests need to include the full fingerprint of both the old and the new key. Not just the key IDs. Not just the new key. We want to be absolutely certain of what you're requesting replaced. I quite like seeing the actual gpg --fingerprint output for both keys because it tends to be quite easy to visually verify. * The new key must be signed by the old key that is being replaced. * The new key must be signed by 2 other keys that are present in the Debian keyring. * The request must be signed by the old key. Signing the request with the new key alone is not helpful - requests must always be signed by a key that is currently in the active keyring. Signing it with both is fine, but not required. * You should specify *why* you want to replace your key. Knowing that it's because you're moving to a stronger key rather than because your old key is compromised / unavailable / on fire helps us prioritise things. This is not what is written here: http://keyring.debian.org/replacing_keys.html Please update that page. In particular, it *requires* a third party to request the key swap on your behalf. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223154937.ga28...@khazad-dum.debian.net
Re: State of the debian keyring
On Sun, 23 Feb 2014, Marco d'Itri wrote: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. (Also, my keyring update request has been waiting for 3 weeks now to be processed.) No. But they should try to sign all[1] keys they had signed with their old key (VERY BIG difference) for which the reason of the signature still remains valid. Anyone has a script to find out the full keyid of all keys that have been signed by a specific [full] keyid? [1] well, I'd skip signing anything below 2048R or expired, *and* require e-mail address verification to weed out expired UIDs somewat. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223155409.gb28...@khazad-dum.debian.net
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 12:28:58PM +0100, Kurt Roeckx wrote: On Sun, Feb 23, 2014 at 07:57:43AM +, Marco d'Itri wrote: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. I'm not sure what you're saying, but I think it's a bad idea. I agree that it's a bad idea. What I would find acceptable is that if you generate an new key you sign the same keys with the new key that you signed previously with the old key. If this is cross signing your own old and new keys, then there is, unrelated to the debian keyring, obviously nothing wrong with that. I would also find it acceptable that the keyring maintainers accept a signature from a single DD to replace the key, with that single DD being the DD's old key. I would not find this acceptable. I'm surprised you write this. Maybe I'm misreading what you meant. If they old key doesn't get revoked there is still a (weak) web of trust. This is true. But I would like to see a signature from at least one other person with a stronger key that has a reasonable connection to the web of trust, preferably a DD. The more then better of course. I think we should use the exact same rules for replacing old keys by new keys as for adding new keys from newcomers. We should not lower the value of new keys by cutting corners. I see no good reason to sign new keys without meeting the person to confirm that that is their new key. I strongly agree with that. You seem to suggest that that is a good idea to keep the web of trust, but to me it seems you just create a web of trust that isn't really there. If your point is that the web of trust with the 4096 bit keys shouldn't depend on the existing web of trust based on the old 1024 bit keys, then I agree. I don't object against keeping the existing web of trust based on the 1024 bit keys, but one should realize that it is already weakened, regardless of how we introduce 4096 bit keys. What we need is a way to confirm that you're talking to the same person you've met previously and confirm that that is his new key. Exactly. We should not cut corners when replacing the 1024 bit keys by 4096 ones. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223162929.ga32...@master.debian.org
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 08:56:46AM -0600, Gunnar Wolf wrote: Marco d'Itri dijo [Sun, Feb 23, 2014 at 07:57:43AM +]: gw...@gwolf.org wrote: So, what do you suggest? Persuade developers that they should sign the new key of people whose old key they have already signed, with no need to meet them in person. I'm open to that if and only if the new keys have proper transition statements. I would never sign new keys based on transition statements. And if the original signatures were *really* done carefully Still never. :-) Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223164726.gb32...@master.debian.org
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 12:49:37PM -0300, Henrique de Moraes Holschuh wrote: On Sun, 23 Feb 2014, Jonathan McDowell wrote: * Requests need to include the full fingerprint of both the old and the new key. Not just the key IDs. Not just the new key. We want to be absolutely certain of what you're requesting replaced. I quite like seeing the actual gpg --fingerprint output for both keys because it tends to be quite easy to visually verify. * The new key must be signed by the old key that is being replaced. * The new key must be signed by 2 other keys that are present in the Debian keyring. * The request must be signed by the old key. Signing the request with the new key alone is not helpful - requests must always be signed by a key that is currently in the active keyring. Signing it with both is fine, but not required. * You should specify *why* you want to replace your key. Knowing that it's because you're moving to a stronger key rather than because your old key is compromised / unavailable / on fire helps us prioritise things. This is not what is written here: http://keyring.debian.org/replacing_keys.html Please update that page. In particular, it *requires* a third party to request the key swap on your behalf. Paragraph 2 on that page states: | If key X is still valid then Alice may sign the request using that key, | but must ensure key Y is signed by key X as well as at least 2 other | active Debian developers whose keys are in the keyring. What would you suggest as alternative wording which is clearer? J. -- Replace repetitive expressions by calls to a common function. This .sig brought to you by the letter M and the number 35 Product of the Republic of HuggieTag -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223172214.gy27...@earth.li
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 04:29:29PM +, Bart Martens wrote: I would also find it acceptable that the keyring maintainers accept a signature from a single DD to replace the key, with that single DD being the DD's old key. I would not find this acceptable. I'm surprised you write this. Maybe I'm misreading what you meant. So maybe this wasn't clear, but I think that should be the exception and clearly not the default. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223183736.ga23...@roeckx.be
Re: State of the debian keyring
On 2014-02-23 17:22, Jonathan McDowell wrote: On Sun, Feb 23, 2014 at 12:49:37PM -0300, Henrique de Moraes Holschuh wrote: This is not what is written here: http://keyring.debian.org/replacing_keys.html Please update that page. In particular, it *requires* a third party to request the key swap on your behalf. Paragraph 2 on that page states: | If key X is still valid then Alice may sign the request using that key, | but must ensure key Y is signed by key X as well as at least 2 other | active Debian developers whose keys are in the keyring. What would you suggest as alternative wording which is clearer? 2. Alice must sign a message with key X, requesting its replacement with key Y. That statement should contain key fingerprints and Debian login details. Key Y must be signed by key X as well as at least 2 other active Debian developers whose keys are in the keyring. If key X is no longer trustworthy (for example, revoked because it was lost or compromised) she must get a Debian developer (ideally not Bob) to make the request on her behalf; this developer must also have performed the appropriate checks to enable them to be comfortable signing key Y. The last sentence still isn't clear to me (or rather, its starting point in the original document is not); should the non-Bob developer also sign the key Y? Is it acceptable for this developer to be the second signatory on the new key, or does a third DD need to be involved? -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 directhex i have six years of solaris sysadmin experience, from 8-10. i am well qualified to say it is made from bonghits layered on top of bonghits -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/61997270efb21e1b1bf9244df2dab...@hogwarts.powdarrmonkey.net
Re: State of the debian keyring
Please update that page. In particular, it *requires* a third party to request the key swap on your behalf. This was also my understanding when I read through this page. It was only just recently that I realised that the exceptional case was first and that the first statement of instruction 2 did not apply: 2. Alice must get a Debian developer (ideally not Bob) to sign a message requesting the replacement of key X with key Y on behalf of Alice. I know I got to the point of doing step 2 ages ago and, having read that requirement, put the rest of the process in the too hard basket. (jmw's suggested reordering of this paragraph helps a lot here) Can I also make a concrete suggestion that the document include a couple of commands to be run to help people know what information to include? We already know that DDs aren't as good with gpg as everyone would like them to be, so including the precise command will help a lot here and save them fighting through gpg documentation again (which is just another barrier to people actually doing this): `gpg --list-sigs 0xNewKeyId` in step 1 `gpg --fingerprint 0xOldKeyId` `gpg --fingerprint 0xNewKeyId` as a step 0 (and perhaps move the paragraphs that are after the steps into numbered steps) The suggestion of automating generating the output with a short script would work too, although it only wants to be a few lines long so that anyone can look at it and trivially understand what it is going to do. cheers Stuart (who has finally mailed RT for the key rollover and will soon find out if he has actually understood the process properly) -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprintBE65 FD1E F4EA 08F3 23D4 3C6D 9FE8 B8CD 71C5 D1A8 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/lee55v$6co$1...@ger.gmane.org
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 12:54:09PM -0300, Henrique de Moraes Holschuh wrote: Anyone has a script to find out the full keyid of all keys that have been signed by a specific [full] keyid? You could look here[0] or use keyanalyze yourself. [0] http://pgp.cs.uu.nl/mk_path.cgi?STAT=EE25DE3F1CDB0FE3STATS=statistics -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140224010413.ga17...@scru.org
Re: State of the debian keyring
On Mon, 24 Feb 2014, Clint Adams wrote: On Sun, Feb 23, 2014 at 12:54:09PM -0300, Henrique de Moraes Holschuh wrote: Anyone has a script to find out the full keyid of all keys that have been signed by a specific [full] keyid? You could look here[0] or use keyanalyze yourself. [0] http://pgp.cs.uu.nl/mk_path.cgi?STAT=EE25DE3F1CDB0FE3STATS=statistics Thanks. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140224014955.gb8...@khazad-dum.debian.net
Re: State of the debian keyring
On Thu, Jan 23, 2014 at 10:07:29PM +, Clint Adams wrote:
The following three reports were generated with debian-keyring
2013.12.13, hopenpgp-tools 0.4-1, jshon 20131010-3, and the
Redone with debian-keyring 2014.01.31, hopenpgp-tools 0.6-1,
jq 1.3-1.1, and attached script:
(/usr/share/keyrings/debian-keyring.gpg)
Total primary keys: 994
Key versions:
994 4
Primary key pubkey algorithms:
611 DSA
383 RSA
Primary key pubkey sizes:
612 1024
27 2048
2 3072
350 4096
2 8192
1 10240
Judgment on preferred hash algorithms of best uid/uat:
540 null
453 weak hash with higher preference
Judgment on expiration times of best uid/uat:
9 expiration passed
30 expiration too far in future
870 no expiration set
84 null
Total number of UIDs + UAts: 4377
Hash algorithm used for most recent self-sig:
1 RIPEMD160
3125 SHA1
1078 SHA256
2 SHA384
171 SHA512
Judgment on preferred hash algorithms:
1252 null
3125 weak hash algorithm
Judgment on expiration times:
50 expiration passed
111 expiration too far in future
3871 no expiration set
345 null
==
(/usr/share/keyrings/debian-maintainers.gpg)
Total primary keys: 205
Key versions:
205 4
Primary key pubkey algorithms:
54 DSA
151 RSA
Primary key pubkey sizes:
54 1024
1 1280
15 2048
1 3072
133 4096
1 8192
Judgment on preferred hash algorithms of best uid/uat:
169 null
36 weak hash with higher preference
Judgment on expiration times of best uid/uat:
3 expiration passed
6 expiration too far in future
161 no expiration set
35 null
Total number of UIDs + UAts: 626
Hash algorithm used for most recent self-sig:
316 SHA1
240 SHA256
70 SHA512
Judgment on preferred hash algorithms:
310 null
316 weak hash algorithm
Judgment on expiration times:
7 expiration passed
18 expiration too far in future
508 no expiration set
93 null
==
(/usr/share/keyrings/debian-nonupload.gpg)
Total primary keys: 9
Key versions:
9 4
Primary key pubkey algorithms:
9 RSA
Primary key pubkey sizes:
1 2048
8 4096
Judgment on preferred hash algorithms of best uid/uat:
9 null
Judgment on expiration times of best uid/uat:
6 no expiration set
3 null
Total number of UIDs + UAts: 25
Hash algorithm used for most recent self-sig:
7 SHA1
16 SHA256
2 SHA512
Judgment on preferred hash algorithms:
18 null
7 weak hash algorithm
Judgment on expiration times:
14 no expiration set
11 null
==
#!/bin/zsh
infile=${1:-/usr/share/keyrings/debian-keyring.gpg}
tempfile=$(mktemp)
trap 'rm ${tempfile}' EXIT
hokey lint --output-format JSON ${infile} ${tempfile}
print -n Total primary keys:
wc -l ${tempfile} # jq '.keyFingerprint' ${tempfile} | wc -l
print Key versions:
jq '.keyVer.val' ${tempfile} | sort | uniq -c
print Primary key pubkey algorithms:
jq '.keyAlgorithmAndSize.pubkeyalgo.val' ${tempfile} | sort | uniq -c
print Primary key pubkey sizes:
jq '.keyAlgorithmAndSize.pubkeysize.val' ${tempfile} | sort -n | uniq -c
print Judgment on preferred hash algorithms of \best\ uid/uat:
jq '.keyBestOf.uidPreferredHashAlgorithms | .[].explanation' ${tempfile} | sort
| uniq -c
print Judgment on expiration times of \best\ uid/uat:
jq '.keyBestOf.uidKeyExpirationTimes | .[].explanation' ${tempfile} | sort |
uniq -c
print -n Total number of UIDs + UAts:
jq '.keyUIDsAndUAts | keys | .[]' ${tempfile} | wc -l
print Hash algorithm used for most recent self-sig:
jq '.keyUIDsAndUAts | .[].uidSelfSigHashAlgorithms | .[].val' ${tempfile} |
sort | uniq -c
print Judgment on preferred hash algorithms:
jq '.keyUIDsAndUAts | .[].uidSelfSigHashAlgorithms | .[].explanation'
${tempfile} | sort | uniq -c
print Judgment on expiration times:
jq '.keyUIDsAndUAts | .[].uidKeyExpirationTimes | .[].explanation' ${tempfile}
| sort | uniq -c
print ==
Re: State of the debian keyring
On Sat, Feb 22, 2014 at 10:41:48PM +, Clint Adams wrote: Redone with debian-keyring 2014.01.31, hopenpgp-tools 0.6-1, jq 1.3-1.1, and attached script: (/usr/share/keyrings/debian-keyring.gpg) [...] Primary key pubkey sizes: 612 1024 For those people who are not aware of this yet, this is really a problem. This provides less security than an 80 bit symmetric cipher. A brute force for this is possible. It's considered to have very short time protection against agencies, short time against medium organisations. That's still 61.5% that's at 1024 bit. CAs are doing better than this, with only 0.8% of the certificates that are still active being 1024 bit. Can I suggest that everyone that is still using a 1024 bit pgp key generates a new key *now*? The recommended minimum size is at least 2048 bit, but I suggest you go for 4096 bit. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2014034641.ga31...@roeckx.be
Re: State of the debian keyring
Kurt Roeckx dijo [Sun, Feb 23, 2014 at 12:46:41AM +0100]: For those people who are not aware of this yet, this is really a problem. This provides less security than an 80 bit symmetric cipher. A brute force for this is possible. It's considered to have very short time protection against agencies, short time against medium organisations. That's still 61.5% that's at 1024 bit. CAs are doing better than this, with only 0.8% of the certificates that are still active being 1024 bit. Can I suggest that everyone that is still using a 1024 bit pgp key generates a new key *now*? The recommended minimum size is at least 2048 bit, but I suggest you go for 4096 bit. ...And now hat you mention this here on the list, we have been discussing how to deal with this for keyring-maint¹. It would clearly be unacceptable for us to decide to lock out 61.5% of Debian because of their old key. Also, removing those keys would most probably make our WoT much more fragile. I'd like to ask the project as a whole for input on how we should push towards this migration. I guess that most of the socially-connected Debian Developers already have 4096R keys. How can we reach those who don't? How can we incentivate them to change? Remember that, in order to get a new key accepted, a big hurdle is sometimes the need for meeting two people with active keys. Several people have started the process to update their keys, but after months (and no real possibility to meet a DD in person) have let it stay as it is. This hurdle is, of course, very important to maintain in order to avoid loosening our identity requirements... So, what do you suggest? -- ¹ Explicitly adding copies to Jonathan and Daniel; Daniel is formally a keyring trainee as per the last delegation mail, and I'm sorry we haven't followed up on his apprenticeship. Daniel, *please* bug us more! :) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223003506.ge30...@gwolf.org
Re: State of the debian keyring
On Sat, Feb 22, 2014 at 06:35:06PM -0600, Gunnar Wolf wrote: I'd like to ask the project as a whole for input on how we should push towards this migration. I guess that most of the socially-connected Debian Developers already have 4096R keys. How can we reach those who don't? How can we incentivate them to change? I've looked at the debconf 2013 keysigning list. 13 people in it had a 1024 bit key, but all of them also had a stronger one. It's clear that the socially-connected DD already moved to a stronger key, and that the problem would then be the others. A few people have already suggested to set a timeline. You also published this policy in 2010: https://lists.debian.org/debian-devel-announce/2010/09/msg3.html Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223005132.ga1...@roeckx.be
Re: State of the debian keyring
Kurt Roeckx dijo [Sun, Feb 23, 2014 at 01:51:32AM +0100]: I'd like to ask the project as a whole for input on how we should push towards this migration. I guess that most of the socially-connected Debian Developers already have 4096R keys. How can we reach those who don't? How can we incentivate them to change? I've looked at the debconf 2013 keysigning list. 13 people in it had a 1024 bit key, but all of them also had a stronger one. It's clear that the socially-connected DD already moved to a stronger key, and that the problem would then be the others. A few people have already suggested to set a timeline. You also published this policy in 2010: https://lists.debian.org/debian-devel-announce/2010/09/msg3.html Right, and we have kept that policy: We no longer accept 1024D keys. However, we didn't anticipate the uptake of stronger keys to be so slow. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223005515.gf30...@gwolf.org
Re: State of the debian keyring
* Gunnar Wolf gw...@gwolf.org, 2014-02-22, 18:35: ...And now hat you mention this here on the list, we have been discussing how to deal with this for keyring-maint¹. It would clearly be unacceptable for us to decide to lock out 61.5% of Debian because of their old key. Also, removing those keys would most probably make our WoT much more fragile. I'd like to ask the project as a whole for input on how we should push towards this migration. A few of 1024 keys have been expired for more than a year. I bet more of them are unused. Perhaps a WAT run would help a bit? -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223012921.ga1...@jwilk.net
Re: State of the debian keyring
On Sat, Feb 22, 2014 at 7:35 PM, Gunnar Wolf gw...@gwolf.org wrote: That's still 61.5% that's at 1024 bit. CAs are doing better than this, with only 0.8% of the certificates that are still active being 1024 bit. Can I suggest that everyone that is still using a 1024 bit pgp key generates a new key *now*? The recommended minimum size is at least 2048 bit, but I suggest you go for 4096 bit. ...And now hat you mention this here on the list, we have been discussing how to deal with this for keyring-maint¹. It would clearly be unacceptable for us to decide to lock out 61.5% of Debian because of their old key. Also, removing those keys would most probably make our WoT much more fragile. I'd like to ask the project as a whole for input on how we should push towards this migration. I guess that most of the socially-connected Debian Developers already have 4096R keys. How can we reach those who don't? How can we incentivate them to change? Has there been any analysis of how active the developers are? I'd hazard to guess that a good number should be moved to emeritus status. Perhaps we should do a ping of developers with 1024 bit keys? -- Andrew Starr-Bochicchio Ubuntu Developer https://launchpad.net/~andrewsomething Debian Developer http://qa.debian.org/developer.php?login=asb PGP/GPG Key ID: D53FDCB1 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAL6k_Axef15jarUVpbU9WC_pBAGUqTHfJdmeHhUV=ta5rcg...@mail.gmail.com
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 8:35 AM, Gunnar Wolf wrote: So, what do you suggest? Set a deadline (say 1 year?) for removal of all 1024 bit keys from the keyring. Notify all users of 1024 bit keys via all addresses listed in the MIA db and all UIDs on those keys. Remind people that coming to DebConf is a great way to get signatures. Talk to the DPL about spending Debian funds to help push this along. At the deadline, move all Debian members still using 1024 bit keys who responded to emeritus status and everyone else to disabled. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6g5qiclm3vfqh1i5c33g7b1rs60wmrjz0-7myrspmb...@mail.gmail.com
State of the debian keyring
I have been asked to share this information.
Firstly, to view a report on your own key, substitute your fingerprint
in the following pipeline:
hkt export-pubkeys --keyring /usr/share/keyrings/debian-keyring.gpg \
4E46 9519 ED67 7734 268F BD95 8F7B F8FC 4A11 C97A | hokey lint
The following three reports were generated with debian-keyring
2013.12.13, hopenpgp-tools 0.4-1, jshon 20131010-3, and the
inefficient script attached. It represents incorrect handling of
revoked UIDs and user attributes, and possibly unknown bugs.
Judgments are based on this document[0] and are not generalized
per key.
The value `null` could mean OK. The term expiration passed
means that the UID or user attribute has expired. The report
format expresses this poorly, but the correlation of 1024-bit
to DSA keys is exactly 1:1 modulo a single 1024-bit RSA key
in debian-keyring.gpg. Subkeys are ignored as irrelevant for
this analysis.
[0] https://we.riseup.net/debian/openpgp-best-practices
(/usr/share/keyrings/debian-keyring.gpg)
Total keys: 996
Key versions:
996 4
Primary key pubkey algorithms:
623 DSA
373 RSA
Primary key pubkey sizes:
624 1024
27 2048
2 3072
340 4096
2 8192
1 10240
Total number of UIDs + UAts: 4394
Hash algorithm used for most recent self-sig:
1 RIPEMD160
3188 SHA1
1041 SHA256
1 SHA384
163 SHA512
Judgment on preferred hash algorithms:
1776 null
2618 weak hash with higher preference
Judgment on expiration times:
53 expiration passed
111 expiration too far in future
3887 no expiration set
343 null
(/usr/share/keyrings/debian-maintainers.gpg)
Total keys: 200
Key versions:
200 4
Primary key pubkey algorithms:
54 DSA
146 RSA
Primary key pubkey sizes:
54 1024
1 1280
13 2048
1 3072
130 4096
1 8192
Total number of UIDs + UAts: 593
Hash algorithm used for most recent self-sig:
294 SHA1
234 SHA256
65 SHA512
Judgment on preferred hash algorithms:
416 null
177 weak hash with higher preference
Judgment on expiration times:
9 expiration passed
18 expiration too far in future
485 no expiration set
81 null
(/usr/share/keyrings/debian-nonupload.gpg)
Total keys: 9
Key versions:
9 4
Primary key pubkey algorithms:
9 RSA
Primary key pubkey sizes:
1 2048
8 4096
Total number of UIDs + UAts: 25
Hash algorithm used for most recent self-sig:
7 SHA1
16 SHA256
2 SHA512
Judgment on preferred hash algorithms:
24 null
1 weak hash with higher preference
Judgment on expiration times:
14 no expiration set
11 null
#!/bin/zsh
infile=${1:-/usr/share/keyrings/debian-keyring.gpg}
tempfile=$(mktemp)
trap 'rm ${tempfile}' EXIT
hokey lint --output-format JSON ${infile} ${tempfile}
print -n Total keys:
jshon -a -e keyFingerprint ${tempfile} | wc -l
print Key versions:
jshon -a -e keyVer -e val ${tempfile} | sort | uniq -c
print Primary key pubkey algorithms:
jshon -a -e keyAlgorithmAndSize -e pubkeyalgo -e val ${tempfile} | sort | uniq
-c
print Primary key pubkey sizes:
jshon -a -e keyAlgorithmAndSize -e pubkeysize -e val ${tempfile} | sort -n |
uniq -c
print -n Total number of UIDs + UAts:
jshon -a -e keyUIDsAndUAts -k ${tempfile} | wc -l
print Hash algorithm used for most recent self-sig:
jshon -a -e keyUIDsAndUAts -a -e uidSelfSigHashAlgorithms -a -e val
${tempfile} | sort | uniq -c
print Judgment on preferred hash algorithms:
jshon -a -e keyUIDsAndUAts -a -e uidPreferredHashAlgorithms -a -e explanation
${tempfile} | sort | uniq -c
print Judgment on expiration times:
jshon -a -e keyUIDsAndUAts -a -e uidKeyExpirationTimes -a -e explanation
${tempfile} | sort | uniq -c
