Back in my day the local telephone company used waxed lacing cable for that sort of thing[1]. These days it seems that polypropylene string is popular (search on "conduit pull string").
You basically want something that is slippery and will tend to not get stuck. I have used Dacron fishing line, but that is mostly because I had a bunch of it laying around.
For me the solution to subpixel issues with tiny fonts is to not do subpixels. I have been looking at bitmapped fonts my whole life so I don't see any reason to give up all that perceptual context.
Which is why I ended up buying a replacement 24" 1920x1080 recently. I needed pixels large enough to distinguish with my fave small font. If I want more pixels at once on the screen I need a larger screen.
I think the two cases are different. The EFAIL researchers were suggesting that the PGP code (whatever implementation) should throw an error on an MDC integrity error and then stop. The idea was that this would be a fix for EFAIL in that the modified message would not be passed on to the rest of the system and thus was failsafe. The rest of the system could not pass the modified message along to the HTML interpreter.
In the gpg.fail case the researchers suggested that GPG should, instead of returning the actual message structure error (a compression error in their case), return an MDC integrity error instead. I am not entirely clear why they thought this would help. I am also not sure if they intended all message structure errors to be remapped in this way or just the single error. A message structure error means that all bets are off so they are in a sense more serious than a MDC integrity error. So the suggestion here seems to be to downgrade the seriousness of the error. Again, not sure how that would help.
In both cases the researchers entirely ignored regular PGP authentication. You know, the thing that specifically is intended to address these sorts of things. The MDC was added as an afterthought to support anonymous messages. I have come to suspect that people are actually thinking of things in terms of how more popular systems like TLS work. So I recently wrote an article based on that idea:
It's occurred to me that it is possible that the GnuPG people are being unfairly criticized because of their greater understanding of how PGP actually works. They have been doing this stuff forever. Presumably they are quite aware of the tradeoffs.
I think it is fair to say that usability is fairly bad for most end to end encrypted systems ... and usability and security are intertwined for E2EE. Here are my comments on Signalgate 1.0:
Regular Bluetooth security is not that great. A lot of it is poor usability where the user can't easily know that they don't have a secure connection. Setting up a secure connection might involve entering a PIN on each end of the connection which might be challenging for something like a pair of earbuds. This contains a nice discussion of the issues and talks about active attacks:
Nothing has improved and everything has gotten worse since I wrote that. Both factions are sleepwalking into an interoperability disaster. Supporting one faction or the other just means you are part of the problem. The users have to resist being made pawns in this pointless war.
>Maybe the new formats in RFC 9580 are indeed "too radical" of an evolutionary step to safely implement in GnuPG.
Traditionally the OpenPGP process has been based on minimalism and rejected everything without a strong justification. RFC-9580 is basically everything that was rejected by the LibrePGP faction (GnuPG) in the last attempt to come up with a new standard. It contains a lot of poorly justified stuff and some straight up pointless stuff. So just supporting RFC-9580 is not the answer here. It would require significant cleaning up. But again, just supporting LibrePGP is not the answer either. The process has failed yet again and we need to recognize that.
>RFC-9580 is basically everything that was rejected by the LibrePGP faction (GnuPG) in the last attempt to come up with a new standard.
That sentence is too long, it should read:
>RFC-9580 is basically everything
The RFC has every idea that anyone involved in its creation ever thought of tossed into it. It's over a hundred pages long and just keeps going and going and going. Want AEAD? We have three of them, two of which have essentially zero support in crypto libraries. PRFs? We've got four, and then five different ways to apply them to secret-key encryption. PKC algorithms? There's a dozen of them, some parameterized so there's up to half a dozen subtypes, including mystery ones like EdDSALegacy which seems to be identical to Ed25519 but gets treated differently. Compression algorithms? There are three you can choose from. You get the idea.
And then there's the Lovecraftian horror of the signature packets with their infinite subtypes and binding signatures and certification signatures and cross-signatures and revocation signatures and timestamp signatures and confirmation signatures and signature signatures and signature signature signatures and signature signature signature aarrgghhh I'm going insane!
The only way you can possibly work with this mess without losing your mind is to look at what { GPG, Sequioa } will accept and then implement a minimal intersection of the two, so you can talk to the two major implementations without ending up in a madhouse.
Here is the short version from someone who took part in this process: while serving as the editor of the draft, Werner did not let anything into the draft that wasn't his own idea. But for his own ideas, there were cases where a new feature was committed to spec master and released in gnupg within the week. He was impossible to work with over many years, to the point that everyone agreed that the only way forward was to leave gnupg behind. This is a bonkers decision for OpenPGP as an ecosystem, but it was not made in ignorance of the consequences. And as far as I'm aware, even with today's hindsight, noone involved in the process regrets making the decision.
Yes, the OpenPGP standards schism was all about personality conflicts. Those conflicts still came from a fundamental difference of philosophy. Who's idea was it to have Koch lead the most recent attempt at a process? Why was that supposed to make a deadlocked process somehow work?
None of this matters now. Everyone is cheerfully walking into an interoperability disaster that will cause much harm. There isn't any real chance GnuPG will lose this war, it is pretty much infrastructure at this point. But the war will cause a lot of harm to the PGP ecosystem, possibly even to the point that it becomes unusable in practice. This is an actual crisis.
Either faction can stop this. But at this point both factions are completely unreasonable and are worthy of criticism.
Sorry, but no. This is not a 50/50 situation where a bonkers position is inexplicably backed by half the populace. There is one faction that is a single person on a large lever, and another who are everybody else. Werner made it clear he will accept nothing less than an unquestioning BDFL hierarchy, but has over many years demonstrated no competence to actually fill that role (TFA being a small example of this).
>And it wants to identify keys by 32-bit truncated hashes.
That's 64 bits these days.
>I should really not have to even think about the interaction between decryption and verification.
Messaging involves two verifications. One to insure that you are sending the message to who you think you are sending the message. The other to insure that you know who you received a message from. That is an inherent problem. Yes, you can use a shared key for this but then you end up doing both verifications manually.
>> And it wants to identify keys by 32-bit truncated hashes.
> That's 64 bits these days.
The fact that it’s short enough that I even need to think about whether it’s a problem is, frankly, pathetic.
> Messaging involves two verifications. One to insure that you are sending the message to who you think you are sending the message. The other to insure that you know who you received a message from. That is an inherent problem. Yes, you can use a shared key for this but then you end up doing both verifications manually.
I can’t quite tell what you mean.
One can build protocols that do encrypt-then-sign, encrypt-and-sign, sign-then-encrypt, or something clever that combines encryption and signing. Encrypt-then-sign has a nice security proof, the other two combinations are often somewhat catastrophically wrong, and using a high quality combination can have good performance and nice security proofs.
But all of the above should be the job of the designer of a protocol, not the user of the software. If my peer sends me a message, I should provision keys, and then I should pass those keys to my crypto library along with a message I received (and perhaps whatever session state is needed to detect replays), and my library should either (a) tell me that the message is invalid and not give me a guess as to its contents or (b) tell me it’s valid and give me the contents. I should not need to separately handle decryption and verification, and I should not even be able to do them separately even if I want to.
>The fact that it’s short enough that I even need to think about whether it’s a problem is, frankly, pathetic.
Please resist the temptation to personally attack others.
I think you mean that 64 bits of hash output could be trivially collided using, say, Pollard's rho method. But it turns out that simple collisions are not an issue for such hashes used as identities. The fact that PGP successfully used 32 bits (16 bits of effort for a collision) for so long is actually a great example of the principle.
>...I should not even be able to do them separately even if I want to.
Alas that is not possible. The problem is intrinsic to end to end encrypted messaging. Protocols like PGP combine them into a single key fingerprint so that the user does not have to deal with them separately. You still have to verify the fingerprint for people you are sending to and the fingerprint for the people who send you messages.
My threat model assumes you want an attacker advantage of less than 2^-64 after 2^64 keys exist to be fingerprinted in the first place, and your threat model includes collisions.
If I remember correctly, cloud providers assess multi-user security by assuming 2^40 users which each will have 2^50 keys throughout their service lifetime.
If you round down your assumption to 2^34 users with at most 100 public keys on average (for a total of 2^41 user-keys), you can get away with 2^-41 after 2^41 at about 123 bits, which for simplicity you can round up to the nearest byte and arrive at 128 bits.
The other thing you want to keep in mind is, how large are the keys in scope? If you have 4096-bit RSA keys and your fingerprints are only 64 bits, then by the pigeonhole principle we expect there to be 2^4032 distinct public keys with a given fingerprint. The average distance between fingerprints will be random (but you can approximate it to be an order of magnitude near 2^32).
In all honesty, fingerprints are probably a poor mechanism.
OK, to be clear, I am specifically contending that a key fingerprint does not include collisions. My proof is empirical, that no one has come up with an attack on 64 bit PGP key fingerprints.
Collisions mean that an attacker can generate two or more messaging identities with the same fingerprint. How would that help them in some way?
Sorry that my, perhaps, poor wording caused you to waste your time producing colliding 64 bit PGP key IDs. I should have used the term "threat model". We were discussing how long key fingerprints should be. My point was that even though 64 bit key IDs are trivially collidable there did not seem to be any practical attacks based on that. So you in a sense provided support for my argument. :) So we can skip directly to your proposed attack...
I have to admit that I don't actually understand it. First the attacker gets some kernel devs to sign key1 of the two keys with colliding key IDs. Why? How does that help the attacker? Then I am guessing that the attacker signs some software with key1. Are the signatures important here? Then the attacker signs the malicious software with key2? Key2 isn't signed by any developers so if that was important the attack fails. If it wasn't important then why mention it?
Could you please provide a more detailed description of the attack? It seems to me that the sort of attack you are describing would require some trusted third party to trick. Like a TLS certifying authority for example.
Why so high? Computers are fast and massively parallel these days. If a cryptosystem fully relies on fingerprints, a second preimage of someone’s fingerprint where the attacker knows the private key for the second preimage (or it’s a cleverly corrupt key pair) catastrophically breaks security for the victim. Let’s make this astronomically unlikely even in the multiple potential victim case.
And it’s not like 256 bit hashes are expensive.
(I’m not holding my breath on fully quantum attacks using Grover’s algorithm, at high throughput, against billions of users, so we can probably wait a while before 256 bits feels uncomfortably short.)
A key fingerprint is a usability feature. It has no other purpose. Otherwise we would just use the public key. Key fingerprints have to be kept as short as possible. So the question is, how short can that be? I would argue that 256 bit key fingerprints are not really usable.
Signal messenger is using 100 bits for their key fingerprint. They combine two to make a 60 digit decimal number. Increasing that to 256 x 2 bits would mean that they would end up with 154 decimal digits. That would be completely unusable.
I was asked about the minimum value, and gave my explanation for why some values could be considered the minimum. By all means, use 256-bit fingerprints.
> I think you mean that 64 bits of hash output could be trivially collided using, say, Pollard's rho method. But it turns out that simple collisions are not an issue for such hashes used as identities.
No. I mean that 64 bits can probably be inexpensively attacked to produce first or second preimages.
It would be nice if a decentralized crypto system had memorable key identifiers and remained secure, but I think that is likely to be a pipe dream. So a tool like gpg shouldn’t even try. Use at least 128 bits and give three choices: identify keys by an actual secure hash or identify them by a name the user assigns or pass them directly. Frankly I’m not sure why identifiers are even useful — see my original complaint about keyrings.
>> ...I should not even be able to do them separately even if I want to.
>Alas that is not possible. The problem is intrinsic to end to end encrypted messaging. Protocols like PGP combine them into a single key fingerprint so that the user does not have to deal with them separately.
Huh? It’s possible. It’s not even hard. It could work like this:
>I mean that 64 bits can probably be inexpensively attacked to produce first or second preimages.
Keep in mind that you would have to generate a valid keypair, or something that could be made into a valid keypair for each iteration. That fact is why PGP got along with 32 bit key IDs for so long. PGP would still be using 32 bit key IDs if it wasn't that someone figured out how to mess with RSA exponents to greatly speed up the process. Ironically, the method with the slowest keypair generation became the limiting factor.
It isn't like this is a new problem. People have been designing and using key fingerprint schemes for over a quarter of a century now.
How do you know that the recipient key actually belongs to the recipient? How does the recipient know that the sender key actually belongs to you (so it will validate correctly)?
Do you mean keyservers? Keyservers have nothing to do with the identity verification required to prevent MITM attacks. There is only one method available for PGP. Comparison of key fingerprints/IDs.
Keyservers are simply a convenient way to get a public key (identity). Most people don't have to use them.
Are you referring to "Encrypted message malleability checks are incorrectly enforced causing plaintext recovery attacks"?
Seems like a legitimate difference of opinion. The researcher wants a message with an invalid format to return an integrity failure message. Presumably the GnuPGP project thinks that would be better handled by some sort of bad format error.
The exploit here is a variation on the age old idea of tricking a PGP user into decrypting an encrypted message and then sending the result to the attacker. The novelty here is the idea of making the encrypted message look like a PGP key (identity) and then asking the victim to decrypt the fake key, sign it and then upload it to a keyserver.
Modifying a PGP message file will break the normal PGP authentication[1] (that was not acknowledged in the attack description). So here is the exploit:
* The victim receives a unauthenticated/anonymous (unsigned or with a broken signature) message from the attacker. The message looks like a public key.
* Somehow (perhaps in another anonymous message) the attacker claims they are someone the victim knows and asks them to decrypt, sign and upload the signed public key to a keyserver.
* They see nothing wrong with any of this and actually do what the attacker wants ignoring the error message about the bad message format.
So this attack is also quite unlikely. Possibly that affected the decision of the GnuPG project to not change behaviour in this case, particularly when such a change could possibly introduce other vulnerabilities.
Added: Wait. How would the victim import the bogus PGP key into GPG so they could sign it? There would normally be a preexisting key for that user so the bogus key would for sure fail to import. It would probably fail anyway. It will be interesting to see what the GnuPG project said about this in their response.
In the course of this attack, just in terms of what happens in the mechanics of the actual protocol, irrespective of the scenario in which these capabilities are abused, the attacker:
(1) Rewrites the ciphertext of a PGP message
(2) Introducing an entire new PGP packet
(3) That flips GPG into DEFLATE compression handling
(4) And then reroutes the handling of the subsequent real message
(5) Into something parsed as a plaintext comment
This happens without a security message, but rather just (apparently) a zlib error.
In the scenario presented at CCC, they used the keyserver example to demonstrate plaintext exfiltration. I kind of don't care. It's what's happening under the hood that's batshit; the "difference of opinion" is that the GnuPG maintainers (and, I guess, you) think this is an acceptable end state for an encryption tool.
You basically want something that is slippery and will tend to not get stuck. I have used Dacron fishing line, but that is mostly because I had a bunch of it laying around.
[1] https://en.wikipedia.org/wiki/Cable_lacing
reply