Wolf: Stop it with those short PGP key IDs!
At his blog, Gunnar Wolf urges developers to stop using
"short" (eight hex-digit) PGP key IDs as soon as possible. The
impetus for the advice originates with Debian's Enrico Zini, who recently
found two keys sharing the same short ID in the wild. The
possibility of short-ID collisions has been known for a while, but it
is still disconcerting to see in the wild. "Those three keys
are not (yet?) uploaded to the keyservers, though... But we can expect
them to appear at any point in the future. We don't know who is behind
this, or what his purpose is. We just know this looks very
evil.
"
Wolf goes on to note that short IDs are not merely human-readable
conveniences, but are actually used to identify PGP keys in some
software programs. To mitigate the risk, he recommends configuring
GnuPG to never shows short IDs, to ensure that other programs do not
consume short IDs, and to "only sign somebody else's key if you
see and verify its full fingerprint. [...] And there are surely many other important recommendations. But this is a good set of points to start with.
"
(Log in to post comments)
Wolf: Stop it with those short PGP key IDs!
Posted Jun 3, 2016 23:53 UTC (Fri) by seb_kuzminsky (guest, #59199) [Link]
It happens. Time for more digits, folks.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 4:01 UTC (Sat) by gwolf (subscriber, #14632) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 3, 2016 23:59 UTC (Fri) by jberkus (guest, #55561) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 0:54 UTC (Sat) by DOT (guest, #58786) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 0:55 UTC (Sat) by k8to (guest, #15413) [Link]
I find the idea alluring.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 1:21 UTC (Sat) by DOT (guest, #58786) [Link]
I think the attacks mentioned in the article are averted especially because no humans can be involved in the conveying of the images. They are easy to scan, but impossible to summarize or copy by hand.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 5, 2016 0:06 UTC (Sun) by lsl (guest, #86508) [Link]
Not anymore! You can also make them look like pictures of Peter Weinberger (the 'w' in awk).
http://research.swtch.com/qart
(the other articles there are worth reading, too)
Wolf: Stop it with those short PGP key IDs!
Posted Jun 7, 2016 23:29 UTC (Tue) by gwolf (subscriber, #14632) [Link]
Daniel's idea is sound and very good, provided every person receiving a nametag is able to check right away that QR's content. I don't know why we have abandoned the idea, but it might be worth pushing again for DebConf this year.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 18:05 UTC (Sat) by cortana (guest, #24596) [Link]
Maybe in 10 years, curve25519 will be more widely supported and keys will be shorter. :)
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 21:58 UTC (Sat) by dsommers (subscriber, #55274) [Link]
When also considering the amount of research efforts in the quantum computing area, this might not be as far away that many would prefer.
But QR encode the full fingerprint and a matching e-mail address, and you might very well have a far better QR code which can download a key easily, regardless of the key size.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 5, 2016 18:05 UTC (Sun) by linuxrocks123 (guest, #34648) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 19:45 UTC (Mon) by dsommers (subscriber, #55274) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 8, 2016 11:27 UTC (Wed) by szbalint (guest, #95343) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 5, 2016 7:56 UTC (Sun) by rmayr (guest, #16880) [Link]
(Disclaimer: In my research group, we design crypto protocols and have been proposing various out-of-band channels for nearly a decade now. The above may therefore be biased.)
Wolf: Stop it with those short PGP key IDs!
Posted Jun 5, 2016 13:44 UTC (Sun) by sprin (guest, #101377) [Link]
I am exploring a system that uses SHA2-256 for OOB verification of a bundle containing a PGP pubkey, a PGP implementation, a form for a message, and some glue code that connects to a HTTP-to-SMTP relay. The idea is to offer a form for first-contact that allows a non-PGP user to send a message end-to-end encrypted with a PGP pubkey. The user receives OOB some brief instructions (brief enough to fit on a business card) and a checksum with which to verify the bundle. Having verified the bundle, they execute the bundle, enter the message and send.
I tested the system last night with a layman friend, who successfully verified the bundle with an online SHA2-256 calculator before sending a message.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 5, 2016 20:13 UTC (Sun) by rmayr (guest, #16880) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 7, 2016 23:31 UTC (Tue) by gwolf (subscriber, #14632) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 1:02 UTC (Sat) by josh (subscriber, #17465) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 5, 2016 19:14 UTC (Sun) by jberkus (guest, #55561) [Link]
Per study: http://arxiv.org/pdf/1510.08555.pdf
Hopefully someday someone will come up with encryption for the masses which is not controlled by some large proprietary softeware company or government agency. But PGP/GPG certainly isn't it.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 5, 2016 19:52 UTC (Sun) by josh (subscriber, #17465) [Link]
(That doesn't by any means make the OpenPGP protocols useless, though; they would work well as a base with usable key management on top. I'm hoping that GPG starts providing a usable OpenPGP library at some point, because no program should need to fork/exec the gpg command-line tool to use GPG.)
Wolf: Stop it with those short PGP key IDs!
Posted Jun 7, 2016 18:40 UTC (Tue) by lsl (guest, #86508) [Link]
Why is that? Calling out to gpg(1) doesn't seem that bad, especially considering the things it does to make it nice to run programmatically (like giving you control over the file descriptors it uses for different kinds of output).
Wolf: Stop it with those short PGP key IDs!
Posted Jun 7, 2016 19:47 UTC (Tue) by josh (subscriber, #17465) [Link]
Note that I'm not necessarily arguing for *just* a standalone libopenpgp that handles key material, though I'd also like that library; a library that talks to gpg-agent to handle key material would be nice. That's possible to build on top of libassuan, but something higher-level would be nice.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 7, 2016 20:08 UTC (Tue) by dd9jn (✭ supporter ✭, #4459) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 7, 2016 20:47 UTC (Tue) by josh (subscriber, #17465) [Link]
Using gpg-agent via assuan seems reasonable, but as far as I can tell, libassuan implements the low-level IPC protocol, not the full details of gpg-agent requests.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 8, 2016 6:16 UTC (Wed) by dd9jn (✭ supporter ✭, #4459) [Link]
Right. gpg currently uses a spawn/use/terminate model but we have not seen any problems with that so that we would need to change it right now. gpgsm however (which has originally been designed with GPGME in mind) is run as a co-process using descriptor passing to avoid creating pipes.
The reason why gpg and gpgsm (and since 2.0 gpg-agent, scdaemon, and dirmngr) are separate processes is to fence the crypto code from other applications by the most rigid separation feature we have in an OS, the process. Thus bugs or exploits in a large GPGME using application won't directly affect the gpg code and thus your keys are better protected. For private keys this goes even further by delegating this to gpg-agent, which could even run on a different box or under a different user.
BTW, we are currently integrating C++ and Python 3 bindings into the GPGME package so that it will be easier to decide which already existing language binding to use (there are several of them, but an "upstream" maintained binding is probably a good choice).
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 8:34 UTC (Mon) by paulj (subscriber, #341) [Link]
PGP may have a learning curve, and requires more hands-on management of the trust, but if you actually need security then that's probably a feature.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 14:06 UTC (Mon) by drag (guest, #31333) [Link]
Of course this is useless for public-facing services... or is it?
If you have DNSSEC and it can be trusted then why not specify a CA through DNS TXT? That way you don't need all these expensive 'trusted roots'. You can make your own and it can be publicly discoverable via DNS records.
Since emails are naturally tied to domain name then automating the creation of private keys and signed client certs should be possible.
If it becomes widespread that email servers can start rejecting non-signed emails then it can end spam as we know it. No more needing to blacklist servers or maintain long spam lists... you just validate the domain. If a domain gets used for spam then you can block trivially based on domain. No email spoofing or anything like that would be possible.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 15:34 UTC (Mon) by drag (guest, #31333) [Link]
I don't see why this scheme can't be extended to support SMTP or any other TLS-enabled service.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 18:07 UTC (Mon) by flussence (subscriber, #85566) [Link]
I imagine it'll become pretty widely supported in other TLS clients, outside of the elephant in the room (which is no surprise, because this technology threatens Mozilla's position as CA gatekeeper).
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 18:23 UTC (Mon) by josh (subscriber, #17465) [Link]
But DNS-based certificates just move the problem around; why do you trust the DNS system and domain registrars, but not CAs? To some extent, CAs cross-check that you're not getting bad data from DNS and the registrars.
Among other things, the main DNS hierarchy has this strange notion that domain names should "expire", and they'll happily sell the name to someone else when it does, at which point they'll also certify the new owner.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 18:49 UTC (Mon) by farnz (subscriber, #17727) [Link]
Two reasons that I think DNSSEC is a net improvement over DV certs:
- My browser's CA list has all sorts of entities in it, any of whom can certify any domain. For example, there's TW and US government certificates in the CA list I'm looking at right now.
- For DV certificates, the CAs don't provide any value; all they do is confirm that at one point in time (details vary between CAs), the domain was controlled by the certificate receiver.
DNSSEC is better than DV certs because the effort required to issue a false DNSSEC cert is higher than that required to issue a false DV cert. You not only need to ensure that you have control of the DNS chain from me to the root, you have to ensure that my cached root key is expired or under your control; for a false DV cert, you merely need to control the DNS chain from the CA to the root at some point in the recent past, so that the CA is conned into issuing a DV certificate.
And the expiry argument applies to DV CA certificates, too - if lwn.net expires, and I pick it up, I can trivially get a DV cert for lwn.net (maybe from Let's Encrypt!). At least with DANE + DNSSEC, I have to maintain control of the domain to con you - I can't just pick it up, get the DV cert, and return it to its rightful owner as a "oops - you let this expire, but I picked it up for you!" generous act.
Having said that, EV certs are better than DNSSEC because the CA ties more than just the domain name to the entity controlling the domain - it also ties a physical world entity to them. I'd like to see DV certs die (which probably eliminates most commercial CAs), but I continue to see a need for EV certs.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 22:56 UTC (Mon) by anselm (subscriber, #2796) [Link]
I'd like to see DV certs die (which probably eliminates most commercial CAs), but I continue to see a need for EV certs.
You probably mean OV (organization-validated) certs, which are the ones where the CA is supposed to satisfy itself that the organization that applies for the certificate exists.
EV certificates are basically OV certificates that look nicer in the browser because the CA in question has a special deal with the browser makers. (Unlike standard DV and OV certificates, you can't make EV certificates yourself with, say, OpenSSL, because EV certificates have special per-CA extensions which are hard-coded into browsers and are checked based on who signed the certificate. You could of course patch Firefox or Chromium but then you would have to get all your users to use that browser and no other.) EV certificates don't usually differ a lot from OV certificates as far as the work that the CA does to verify the organization behind the certificate is concerned, but are vastly more expensive just so you can get that green bar in your browser's URL field. Essentially, EV certificates were the CAs' way of saving their bottom line in the face of constantly-dropping prices for OV certificates. The “race to the bottom” has now started for EV certificates, too, and we can only wait for the CAs to come up with, say, “extra-validated” (XV) certificates which will be marketed as “even more secure than EV certificates” and of course be five times as expensive.
Since HTTPS these days is mostly security theatre in the first place, there is little point in wasting money on expensive certificates. From a practical POV, there is no compelling reason to pay for an OV certificate over a (free) DV certificate – users won't be able to tell the difference –, and pretty much the only reason to get an EV certificate is if you're operating in a market where all your competitors have one, and you don't want to appear to be lax on “security” (think “bank”).
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 19:58 UTC (Mon) by drag (guest, #31333) [Link]
Because there is no real way to validate that the CA is supposed to be providing certificates for a particular domain.
If I sign a cert for a domain from 'Good Guy. Inc'... there is no technical measures in place to prevent somebody using any other CA to sign their own certs for my domain. As long as governance for CAs are rock solid then this isn't a problem. Unfortunately the security for any cert is only as good as the weakest CA the clients trust. If your client software is configured to trust 300 different CAs then the security for all those CAs must be good for any of the their certs to be really trustworthy.
With DNSSEC I only have to trust the domain operator and TLD it depends on to get it right, if they choose to manage their own CA. That cuts a huge number of people (aka, potential issues) out of the equation. It can make self-signed CAs a sane solution use as well.
> Among other things, the main DNS hierarchy has this strange notion that domain names should "expire", and they'll happily sell the name to someone else when it does, at which point they'll also certify the new owner.
Sure, but as long as you control domain you should be able to control what CAs clients trust without having to have those clients pre-configured to do so.
This means that all sorts of tasks that require signing and encryption that can depend on asymmetrical encryption schemes can be automatically configured via DNS records explicitly setting the CA information. Signing messages, signing packages, encrypting websites, vpns, client auth, instant messaging, VoIP, etc etc. All this can be done automatically and securely.
(Possibly. I know there are problems.)
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 20:06 UTC (Mon) by drag (guest, #31333) [Link]
If you lose control of your private keys then you can work with the TLD to update the DNSSEC records to trust a different CA then all clients should, in short order, start rejecting certs made by the old CA.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 7, 2016 0:50 UTC (Tue) by flussence (subscriber, #85566) [Link]
That's correct, but Mozilla owns the whitelist that everything else on an average Linux system uses. Moreover, that list excludes CACert, which is the only traditional CA I'm aware of that provides assurances beyond the bare minimum required to comply with the letter of such an audit.
>But DNS-based certificates just move the problem around; why do you trust the DNS system and domain registrars, but not CAs?
I can make myself part of the DNSSEC chain of trust just by giving the registrar the public half of my zone-signing key, pointing them at my server, and waiting for the changes to propagate. That means I have to trust, at most, four things: the DNS root, the TLD servers, the registrar's security, and my own system security. Note that using CAs doesn't make any of these go away.
I've seen enough people get burned by things like StartSSL post-heartbleed and the CNNIC "oil spill" of forged certs that I don't have much faith left in the bookkeepers and their policies. I'd rather not stick my head in the sand and pretend the other 200 points of failure in that list will never fail when there's a better option.
>To some extent, CAs cross-check that you're not getting bad data from DNS and the registrars.
DNSSEC doesn't preclude the use of an external CA. It allows key-pinning at the DNS level, similar to the HTTP pinning currently in browsers.
>Among other things, the main DNS hierarchy has this strange notion that domain names should "expire", and they'll happily sell the name to someone else when it does, at which point they'll also certify the new owner.
DNSSEC wouldn't make serving domain squatter pages over HTTPS any easier than ACME does, so it's not a point either way.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 18:27 UTC (Mon) by wahern (subscriber, #37304) [Link]
Until recursive-capable resolver libraries becomes more widespread, I don't think we can expect DNSSEC to be used that way. AFAIU, part of the reason Mozilla and Chrome soured on DANE (DNSSEC+TLS) and DANE-like solutions was because they'd have to support recursive resolution in-browser.
FWIW, I have a non-blocking I/O DNS resolver that does recursive resolution: https://github.com/wahern/dns and http://25thandclement.com/~william/projects/dns.c.html. Adding DNSSEC is on my TODO list. It's a single-file .c library[1] which is quite long, partly because of the various record-specific code. But recursive resolution is nonetheless much more involved than stub resolution. Not in an absolute sense, but a stub resolver can be so incredibly simple that recursive resolution is much more complex by comparison.
[1] Single-file makes it easy to embed into projects, without saddling the project with build-time or run-time dependencies.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 19:19 UTC (Mon) by drag (guest, #31333) [Link]
> Do you trust your ISP's DNS servers enough?
This is one of those 'trust but verify' situations. If you have a DNS server sending out phony DNSSEC information then it's going to be pretty trivial to discover, provided somebody takes the time to write a utility to do it. If have a nice script to validate a questionable DNS server with a known good DNS server.. then how many domains could you validate in a half a hour or so?
If the ISP is jacking with DNS then it isn't going to be something that is difficult to find out.
Personally I think that the best solution for this sort of thing is to have the OS provide more sophisticated name resolution validation as a service to applications, like running a local DNS resolver or whatever. Until that happens then having the option to use better libraries is probably a good thing, of course.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 19:53 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Just switch to systemd ;)
https://www.freedesktop.org/software/systemd/man/resolved... - look for DNSSEC. They're switching it to allow-downgrade in the next release.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 7, 2016 8:08 UTC (Tue) by paulj (subscriber, #341) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 7, 2016 18:59 UTC (Tue) by lsl (guest, #86508) [Link]
If you need the ability to subvert DNSSEC validation at a click of the mouse (people seem to require this "feature"), there's even a GUI tool for that.
See:
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_...
Other distributions (and FreeBSD) have similarly convenient ways to set this up.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 7, 2016 20:53 UTC (Tue) by raven667 (subscriber, #5198) [Link]
I don't think spoofing is a problem right now, spammers are _more_ likely to use SPF records for example or DV certs because they automate the provisioning of domain names with all the legitimate resources that go with them, they just don't care if the domain is usable for more than a day.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 10, 2016 10:09 UTC (Fri) by robbe (guest, #16131) [Link]
> If a domain gets used for spam then you can block trivially based
> on domain.
Only workable if there were a very high setup cost for domains (hopefully offset by much lower yearly fees). And then it sounds like „bonded email“ proposals I’ve all but forgotten about.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 17:39 UTC (Mon) by dd9jn (✭ supporter ✭, #4459) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 1:02 UTC (Sat) by xtifr (guest, #143) [Link]
Huh. Sounds like a bug in those programs (unless it merely offers the keys as a _possible_ match).
If it weren't for that, though, I'd say these fears are a little overblown. But if that's true, then yeah, we have a problem. And while there may be technical fixes for individual cases, the fact that it's occurring suggests we have a broader social problem. So yeah, I'm ok with Wolf's suggestion.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 17:07 UTC (Sat) by dd9jn (✭ supporter ✭, #4459) [Link]
Because most people do not know about putting "keyid-format long" into their gpg.conf, we are currently discussion to drop the keyid from the key listing and show the fingerprint instead. See https://bugs.gnupg.org/gnupg/issue2379
Wolf: Stop it with those short PGP key IDs!
Posted Jun 5, 2016 21:39 UTC (Sun) by josh (subscriber, #17465) [Link]
When would fingerprints *not* be available?
Wolf: Stop it with those short PGP key IDs!
Posted Jun 5, 2016 22:25 UTC (Sun) by christoph_d (guest, #62481) [Link]
Obviously that requires having the public key.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 5, 2016 22:47 UTC (Sun) by josh (subscriber, #17465) [Link]
Is there any extension or mechanism to embed the complete fingerprint of the signing key, in a way that GPG and ideally other OpenPGP clients would understand?
on OpenPGP signature not embedding the complete fingerprint
Posted Jun 6, 2016 1:25 UTC (Mon) by dkg (subscriber, #55359) [Link]
It's a bug in the OpenPGP standard that the full fingerprint of the signing key is not included in each signature. it's one of the things that will be fixed in the upcoming revision of the OpenPGP standard.
on OpenPGP signature not embedding the complete fingerprint
Posted Jun 6, 2016 17:47 UTC (Mon) by dd9jn (✭ supporter ✭, #4459) [Link]
I wish we could make faster progress in rfc4880bis so that a signer-fingerprint could be added to software now as an option.
on OpenPGP signature not embedding the complete fingerprint
Posted Jun 7, 2016 23:48 UTC (Tue) by gwolf (subscriber, #14632) [Link]
If nothing else does, *this fact* seems of utmost severity. Then, for all practical purposes, the signature's strength is only 64 bits. Which is not trivial, but is a far cry from 160 bits.
If this change enters the new OpenPGP standard, how long will it take for most implementations in the wild to carry it? I guess saying 3-5 years is not too conservative.
on OpenPGP signature not embedding the complete fingerprint
Posted Jun 8, 2016 6:22 UTC (Wed) by dd9jn (✭ supporter ✭, #4459) [Link]
on OpenPGP signature not embedding the complete fingerprint
Posted Jun 10, 2016 9:31 UTC (Fri) by robbe (guest, #16131) [Link]
Ok, with a work factor of 2^64, you are able to generate a key that matches the one that was signing a given message. But what are you going to do with it?
The only thing I can imagine amounts to DoS: smuggle the fake key to the recipient, resulting in failed verfication. Sure, it’s not nice, and may induce the recipient to make human errors. But it’s not the same as a forged signature (that you get with 2^160).
on OpenPGP signature not embedding the complete fingerprint
Posted Jun 10, 2016 14:03 UTC (Fri) by dkg (subscriber, #55359) [Link]
yes, the DoS is one potential problem.Another way to look at the issue is that when writing an MUA (or other signature-verifying system), if you discover a signature that doesn't appear to verify, it's unclear how to describe this problem to the user. Do you say "this signature is broken" or "this signature may have been made by a different key" or something entirely different?
This kind of unnecessary ambiguity and confusion for implementers and users is one of the thousand papercuts that discourage people from using strong crypto. What does using the keyid instead of the full fingerprint save us? 12 octets per signature, in signatures that (these days) are hundreds of octets in length. It's a terrible tradeoff.
on OpenPGP signature not embedding the complete fingerprint
Posted Jun 10, 2016 20:03 UTC (Fri) by dd9jn (✭ supporter ✭, #4459) [Link]
Now if we move to S/MIME, we get into worse problems, because there are many different ways to denote a required key and none of them are guaranteed to work. You more or less have to pick a method on good luck and hope that the mentioned LDAP server is up and running and actually has the certificate you need - or well all of them, and those for the CRL, ...
on OpenPGP signature not embedding the complete fingerprint
Posted Jun 10, 2016 20:27 UTC (Fri) by dkg (subscriber, #55359) [Link]
dd9jn said:I doubt that anyone has seen the problem you describe in the second paragraph in real life.Really? I ran into that ambiguity/confusion myself when working on the UI/UX for the OpenPGP signature verification functionality for notmuch. As an implementer planning out how to deal with bad scenarios, it's quite unclear how to present this sanely to the user in a way that they can take reasonable action. Colliding long keyIDs exist, and will only become more common over time.
fwiw, i totally agree with you that the many ways S/MIME has to fetch keys are often broken. I'm not recommending that we adopt them all for OpenPGP!
on OpenPGP signature not embedding the complete fingerprint
Posted Jun 13, 2016 6:40 UTC (Mon) by dd9jn (✭ supporter ✭, #4459) [Link]
I consider to put the mail address into the signature as another method to lookup the key. With that old PKA method this was already possible but I meanwhile consider a separate signature sub-packet a better idea because that does not mingle key discovery with key validation (which is combined in PKA).
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 11:22 UTC (Mon) by fredrik (subscriber, #232) [Link]
BTW, is there any way to configure gnupg to always include the full key fingerprint? Just as if the argument "--with-fingerprint" was there by default to any command where it makes sense.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 14:43 UTC (Mon) by ms (subscriber, #41272) [Link]
Yes. https://help.riseup.net/en/security/message-security/open...
"You should probably at least set keyid-format 0xlong and with-fingerprint gpg options (put them in ~/.gnupg/gpg.conf) to increase the Key ID display size to 64-bit under regular use, and to always display the fingerprint"
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 2:09 UTC (Sat) by alvherre (subscriber, #18730) [Link]
Strangely enough, the second key (which looks like a fake to me) also has some signatures, and the short-PGP-IDs of the signing keys match the short-PGP-IDs of signers of the real key. You can see for example a signature by key 0x0E357287 (which happens to be an old key of mine), which is also a signer of the fake key -- except that the signing keys are two different keys which happen to have the same short-PGP-ID. And there are also signatures by Rafael Martínez Guerrero and Samuel Pizarro Silva, where somebody managed to create fake keys sharing short-PGP-IDs for those email addresses too.
I think this is an actual attempt at some sort of attack, even though I don't actually use my key for anything so I can't see what it is that they are attacking.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 3:14 UTC (Sat) by FrankL (guest, #108226) [Link]
How much effort does it take to generate fake keys? i.e. how much effort is 'someone' taking to try and fake people's identities?
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 3:30 UTC (Sat) by dtlin (subscriber, #36537) [Link]
Evil 32: Check Your GPG FingerprintsUsing modern GPUs, we have found collisions for every 32bit key id in the WOT's (Web of Trust) strong set. […] It takes 4 seconds to generate a colliding 32bit key id on a GPU (using scallion).Since 2014!
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 4:02 UTC (Sat) by FrankL (guest, #108226) [Link]
It'd be interesting to analyze all the keys in the WoT and list collisions with email addresses that have the same name or a variation on the name (i.e. an indication of someone trying to fake an identity).
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 4:21 UTC (Sat) by gwolf (subscriber, #14632) [Link]
Yes, I have got few further reports of people with similar situations... I don't think these keys are the Evil32 ones, as I would not expect them to attempt to create the whole set of cross-signatures as well, but it is a possibility. And FWIW, it would be the best of all, just to classify us all as (rightful) paranoids. But anyway, we _do_ need to change several of our practices towards better security!
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 4:34 UTC (Sat) by gwolf (subscriber, #14632) [Link]
Also: Among the signers for your fake key, there are currently two named ones (Rafael and Samuel). I have signed your real key with 0x673A03E4C1DB921F, and as expected — my evil twin 0x15FBFDEDC1DB921F signed your evil twin's key. Only that my evil twin hasn't made its way to the keyserver network.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 5, 2016 11:25 UTC (Sun) by tao (subscriber, #17563) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 5, 2016 8:01 UTC (Sun) by rmayr (guest, #16880) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 8:46 UTC (Mon) by paulj (subscriber, #341) [Link]
The 2014-06-16 one isn't my key. They've recreated some of the signatures too.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 8:24 UTC (Sat) by ewx (guest, #103004) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 7, 2016 23:57 UTC (Tue) by gwolf (subscriber, #14632) [Link]
:signature packet: algo 1, keyid 587979573442684E
version 4, created 1249167784, md5len 0, sigclass 0x13
digest algo 8, begin of digest 27 b2
hashed subpkt 2 len 4 (sig created 2009-08-01)
subpkt 16 len 8 (issuer key ID 587979573442684E)
data: [4095 bits]
Yes, it would be much better were they to carry the 160 bits... But at least they are not limited to 32!
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 11:05 UTC (Sat) by jaromil (guest, #97970) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 14:16 UTC (Sat) by eduard.munteanu (guest, #66641) [Link]
Unfortunately, I don't think even GnuPG does the right thing if faced with colliding fingerprints.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 17:09 UTC (Sat) by dd9jn (✭ supporter ✭, #4459) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 5, 2016 4:20 UTC (Sun) by eduard.munteanu (guest, #66641) [Link]
I wish crypto strength had been scaled better, in hindsight. A few years is really short-term in this field and we've already been racing against technology with things like MD5, DES and short RSA keys. Considering much stronger algorithms are available for a slight increase in costs, there's really no reason to keep repeating mistakes.
I was planning on writing a small crypto tool based on NaCl/libsodium. Perhaps I should get started.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 5, 2016 8:03 UTC (Sun) by dd9jn (✭ supporter ✭, #4459) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 4, 2016 16:19 UTC (Sat) by flussence (subscriber, #85566) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 5, 2016 16:31 UTC (Sun) by kjp (guest, #39639) [Link]
Wolf: Stop it with those short PGP key IDs!
Posted Jun 7, 2016 0:10 UTC (Tue) by AnthonyJBentley (guest, #71227) [Link]
The author of signify, Ted Unangst, also wrote a tool called reop.
The interface is so much simpler than GPG. Just a few commands:
usage: reop -G [-n] [-i ident] [-p pubkey -s seckey]
reop -D [-i ident] [-p pubkey -s seckey] -m message [-x encfile]
reop -E [-1b] [-i ident] [-p pubkey -s seckey] -m message [-x encfile]
reop -S [-e] [-x sigfile] -s seckey -m message
reop -V [-eq] [-x sigfile] -p pubkey -m message
(Generate, decrypt/encrypt, sign/verify)
And comes with a simple but entirely complete manpage:
$ man reop | wc -l
102
$ man gpg | wc -l
3233
I know a handful of people with reop keys, mostly OpenBSD folks. But despite having been to multiple Linux User Groups and cryptoparties, I’ve never received a single OpenPGP‐encrypted mail… so it’s not like reop’s low adoption actually affects me in a meaningful way.
Alas, reop’s development has stalled. But even if reop is not the end solution, I firmly believe OpenPGP implementations could stand to learn from the simplicity of its interface.
Wolf: Stop it with those short PGP key IDs!
Posted Jun 8, 2016 1:26 UTC (Wed) by kjp (guest, #39639) [Link]
signify public keys are not shorter than OpenPGP v4 fingerprints.
Posted Jun 6, 2016 1:30 UTC (Mon) by dkg (subscriber, #55359) [Link]
I think you're talking about signify.Signify uses ed25519. Its public keys are 255 bits long (round that up to 256 bits).
OpenPGP v4 fingerprints are 160 bits long.
signify public keys are not shorter than OpenPGP v4 fingerprints.
signify public keys are not shorter than OpenPGP v4 fingerprints.
Posted Jun 6, 2016 17:52 UTC (Mon) by flussence (subscriber, #85566) [Link]
Of course, that doesn't change the fact that it's only a fingerprint...
Wolf: Stop it with those short PGP key IDs!
Posted Jun 5, 2016 8:43 UTC (Sun) by biergaizi (guest, #92498) [Link]
http://pgp.gwolf.org/pks/lookup?op=vindex&search=0xa0...
Nevertheless, I have never thought deliberate attacks are not that difficult...
Wolf: Stop it with those short PGP key IDs!
Posted Jun 6, 2016 15:00 UTC (Mon) by brian_lindholm (subscriber, #42351) [Link]