OpenPGP for application developers
This document is not intended for end-users or implementers of OpenPGP libraries (or other software that directly handles internal OpenPGP data structures).Instead, this document is focused on the second group, application developers, who use OpenPGP functionality in their software projects. It describes the properties of the OpenPGP system and its uses. It presupposes solid knowledge of software development concepts and of general cryptographic concepts. Thus, this text describes OpenPGP at the “library-level,” teaching concepts that will help software developers get started as a user of any implementation (e.g., OpenPGP.js, Sequoia-PGP).
Posted Dec 13, 2023 18:13 UTC (Wed)
by simon.d (guest, #168021)
[Link] (65 responses)
Posted Dec 13, 2023 21:20 UTC (Wed)
by ballombe (subscriber, #9523)
[Link] (33 responses)
Posted Dec 13, 2023 22:21 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link] (32 responses)
(Posting signed messages to a public mailing list, when there's no obvious reason to believe that anyone would even try to falsify them, let alone get away with doing so, does not count as a "serious purpose.")
Posted Dec 14, 2023 7:22 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link] (31 responses)
Posted Dec 14, 2023 13:38 UTC (Thu)
by pizza (subscriber, #46)
[Link] (16 responses)
And "all the alternatives are provided by organizations that epitomize the threat model [1] that PGP was designed to protect against."
I'm not going to try and claim that the existing MUA PGP UIs aren't awful, but the underlying problem here is that the problem space here is inherently user-unfriendly, extends well beyond the bounaries of the MUA itself, and requires continual user buy-in and awareness of what's going on.
It turns out that hardly anyone [2] _needs_ this level of ongoing protection, so it's not considered worth the (initial or ongoing) effort to utilize it.
[1] ie "a _completely_ untrused (and untrustable) communications channel"
Posted Dec 14, 2023 14:59 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
* Backwards compatibility with cipher suites deprecated 10+ years ago, and a reluctance to introduce new cipher suites or modes. Contrast with TLS 1.3, where you either get a secure cipher suite, or a connection error.
All of these are very bad problems. Characterizing it as just "UX is hard" is a gross simplification of a large and (probably) intractable problem.
Posted Dec 14, 2023 15:41 UTC (Thu)
by pizza (subscriber, #46)
[Link] (1 responses)
This is _intentional_ because the alternative is to force you to continually refresh your stored/at-rest data or lose access to it.. Arguably you should be doing that anyway, but then you lose the metadata/attestations of the original message. Which may or may not matter.
(I also know from experience that you often don't get a choice in what you're communicating with, and there are lessons to be learned from OpenSSH's removal of old ciphersuites that effectively results in downgrading users to using telnet, reducing the investment needed to perform an attack to $0)
> Lack of forward secrecy. No plausible path to introducing forward secrecy.
True; this really isn't implementable in the usage model that PGP was built around.
> Excessive overall complexity. Trying to do too many things, and doing them all poorly.
....Still waiting on the alternatives for many of those things, much less done _well_.
> Web of trust never worked and never will.
Turns out it doesn't scale, but it works well enough for its intended use cases.
The CA-based PKI system is also a cluster-f, and has its own intractible problems.
> You leak the fact that Alice sent a message to Bob on such-and-such date, and this is likely tied to Alice and Bob's real identities.
Eh, that's a function of _email_ not PGP specfically. There's nothing that forces folks to use their real names or identities in any given email account, and any metadata that leaks/ties back to their real identities can be gleaned from nearly any other mechanism too. (As lots of TOR users have learned!)
This metadata leakage is a fundamental nature of any communication channel. You can't hide the fact that communication is taking place (and when); at best you can hide the recipient, but not the sender, nor when. The best you can do is delay interception by "long enough"
Posted Dec 14, 2023 19:27 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link]
Of course it's intentional. That is not a rebuttal. Bad design is bad, even if you made it that way deliberately.
> but then you lose the metadata/attestations of the original message.
Validate those attestations and metadata when the message is received, sign the validation with your own key(s), and store/refresh the validations as needed.
> (I also know from experience that you often don't get a choice in what you're communicating with, and there are lessons to be learned from OpenSSH's removal of old ciphersuites that effectively results in downgrading users to using telnet, reducing the investment needed to perform an attack to $0)
Well, it depends. If you know, ahead of time, that you're communicating in cleartext, then you're probably not going to conduct any sensitive business in cleartext. OTOH, if the cipher suite is weak, it's much less likely that the user will know or care about that, so it increases overall risk in comparison to a known-cleartext channel.
> ....Still waiting on the alternatives for many of those things, much less done _well_.
The article suggests several alternatives, some of which are FOSS. If good FOSS alternatives don't exist, I think that's more an indictment of FOSS than a validation of PGP.
> The CA-based PKI system is also a cluster-f, and has its own intractible problems.
Meh, things are still not great, but between mandatory certificate transparency, and the high-profile distrusting of a few large CAs in the recent past, I think it's less of a problem today than it was (say) 10 years ago. Nowadays, it's fairly obvious that you either behave, or the CA/B drops your root.
> Eh, that's a function of _email_ not PGP specfically.
PGP encourages you to tie your key to a real-world identity, and then upload that information to a keyserver (where it will then be replicated onto other keyservers). Email addresses can be and often are pseudonymous.
Posted Dec 14, 2023 15:30 UTC (Thu)
by paulj (subscriber, #341)
[Link] (11 responses)
Posted Dec 14, 2023 17:00 UTC (Thu)
by pizza (subscriber, #46)
[Link] (10 responses)
(Granted, it's often difficult to do that surreptitiously, but as you demonstrated, you don't have to gympie the sender or recipient, just a nameless middleman)
[1] A type of club hammer typically used to "persuade" things into (or out of) place.
Posted Dec 15, 2023 10:12 UTC (Fri)
by james (subscriber, #1325)
[Link] (8 responses)
Posted Dec 15, 2023 13:56 UTC (Fri)
by kleptog (subscriber, #1183)
[Link] (6 responses)
FWIW the Dutch highest court ruled the chats are admissible as evidence as long as the legal basis for collection in France is valid. There were some very nasty criminals using it, but also lawyers.
Posted Dec 15, 2023 14:32 UTC (Fri)
by pizza (subscriber, #46)
[Link] (5 responses)
...Just because the compromise was done "legally" (versus, say, phishing or via a gympie) doesn't make it any less of a compromise.
Posted Dec 15, 2023 17:00 UTC (Fri)
by kleptog (subscriber, #1183)
[Link] (4 responses)
> The unauthorized disclosure, modification, substitution, or use of sensitive data (e.g., keys, metadata, or other security-related information) or the unauthorized modification of a security-related system, device or process in order to gain unauthorized access.
At no point were any changes made to the hosting company that were unauthorised by the hosting company. So it's a bit difficult to argue they were compromised. Changes were made to the Encrochat server without the authorisation of the managers thereof, so they at least have a claim of being compromised.
One of the important components of "unauthorised" is that you don't know what's happening. Which in this case doesn't apply to the hosting company.
Posted Dec 15, 2023 18:57 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link]
Posted Dec 15, 2023 19:29 UTC (Fri)
by pizza (subscriber, #46)
[Link] (2 responses)
Are you seriously trying to argue that the end users "authorized" the powers that be to intercept or otherwise access their communications?
By your definition, during WW2 Bletchley Park didn't "compromise" the German Enigma system, because they'd been "authorized" by the British Government to do so.
Posted Dec 15, 2023 20:32 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Dec 16, 2023 22:39 UTC (Sat)
by kleptog (subscriber, #1183)
[Link]
Just like if I'm red teaming at a customer, if I break into their AD, it's not a compromise because I'm authorised to do it.
Exactly the same modification to a system can be considered a compromise or not, depend on which party you are.
Posted Dec 18, 2023 11:23 UTC (Mon)
by paulj (subscriber, #341)
[Link]
The interesting thing here is that the EncroChat messaging system apparently was robust (least, not the weak link), and gave the criminals their desired end-to-end security. The problem - it seems - is that EncoChat had left in a system to update the software. So LEA exploited that by gaining control of the update server, modifying the chat client to log and send on copies of chats, and pushed that update out via the update servers.
So, an important lesson here is to sign your software, and keep strict control of the signing system, and keep the signing system away from the distributiobn process. Develop the app securely, ensure it's the right version, and sign that, all offline (least, not on servers easily found by your attacker).
Posted Dec 17, 2023 21:20 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
I first thought of the "gympie-gympie"[1] which may rival it for such…persuasion.
Posted Dec 17, 2023 19:46 UTC (Sun)
by eharris (guest, #144549)
[Link]
Really? Diffie/Hellman and primes bigger than, say, 30,00 bits are quite within the capability of ordinary folk!
<MESSAGE>
Posted Dec 14, 2023 14:43 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (12 responses)
Frankly, I'm a bit tired of FOSS advocates claiming that proprietary alternatives are not real alternatives. If FOSS doesn't solve a given problem, that is not the same thing as the problem not being solved at all. You are free to not use proprietary software, and to advocate for greater use of FOSS. But if there is no reasonable FOSS alternative, sometimes your only choices are proprietary, rolling your own, or not doing the thing.
(There's also the question of whether the FOSS model is even well-suited to developing crypto software in the first place, given its complexity and the sheer number of CVEs we've seen from the FOSS side of the crypto space, but there are at least some FOSS projects that do crypto well, so I think that may be an overly reductive take. Still, FOSS options for end-user-facing crypto software seem to be lacking at the moment.)
Posted Dec 15, 2023 16:38 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (11 responses)
Posted Dec 15, 2023 17:48 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (3 responses)
I know we FLOSS fanatics tend to confuse the two terms but they are very different. "Proprietary" means "someone owns it". That INCLUDES things like Linux, GCC, yada yada. Okay, when something is owned by maybe 1000 (and the rest) proprietors, it can be very difficult to get permission from all of them (which is why we have the GPL, but that wouldn't work if GCC and Linux didn't have proprietors ...)
And I've worked for plenty of companies who had "proprietary" solutions supplied as source. Why not? That was "Original Unix", wasn't it ... ?
Cheers,
Posted Dec 15, 2023 18:56 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
Posted Dec 15, 2023 20:01 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
It might actually have been Microsoft that did it, I don't know. But the meaning here is not the common meaning, and the meaning here is MUCH YOUNGER than the common meaning.
After all, proprietors normally hold OPEN HOUSE, don't they? :-)
Cheers,
Posted Dec 16, 2023 14:48 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
Iirc it was part of Microsoft's marketing campaign - Unix (supplied as source!) was proprietary and expensive, only running on expensive kit, while Windows was Open and Cheap, and ran on any old kit.
That re-definition, in turn, got taken over by the Free Software crowd (who lost the original meaning of "has a proprietor", or owner) and turned against Microsoft, along with the coining of EEE.
Cheers,
Posted Dec 18, 2023 6:05 UTC (Mon)
by NYKevin (subscriber, #129325)
[Link] (6 responses)
Well, that and "If we turn out to be lying, then our whole business goes up in smoke." See for example the CA/B process (which PGP people love to dump on, but it actually has gotten a lot better at revoking bad roots in recent memory).
Posted Dec 18, 2023 6:28 UTC (Mon)
by LtWorf (subscriber, #124958)
[Link]
The invisible hand doesn't exist.
Posted Dec 18, 2023 16:01 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (4 responses)
Which of course the EU is currently trying to do an end-run around under the auspices of the upcoming revised eIDAS regulation, by forcing browsers to include root CA certificates from government-approved CAs that the browser makers don't get to vet.
Posted Dec 18, 2023 17:03 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (2 responses)
It may not be the simplest thing for most users, but if a user can modify the source of the browser, it'll be easy to delete those root certs.
Cheers,
Posted Dec 19, 2023 10:39 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (1 responses)
Patching and recompiling a major browser is not for the faint of heart (or those with small(ish) PCs). I think, since the browser makers won't be able refuse the QWAC root CA certificates outright, what we may eventually see are improvements to browser trust store management UIs that will let people deselect root CA certs they don't like in a more convenient manner (including a guarantee that they won't pop up again on the next browser update). Also the fact that browsers generally do their own thing, apart from the OS, when it comes to trust store management is a problem because it is difficult to figure out all the places where you would have to go to remove those certs. It would certainly change the situation in the EU from the current “mostly works OK by default for most people” to “sucks for almost everyone” since only the very dedicated would go to the trouble of adjusting their trust store.
This is apart from the fact that there will probably be subtle (or not-so-subtle) pressure on web sites, certainly the major ones, to use QWAC certificates from the government-approved CAs, in order to make life more difficult for those people who do decide to patch out those root certificates. After all, the whole thing seems to be driven not just by a desire to make it easier for state actors to MITM people's connections, but also to generate money-making opportunities for commercial CAs whose business has mostly been killed by the likes of Let's Encrypt. After all, QWAC certificates from the government-mandated CAs are basically just like EV certificates, which go for €€€ but which nobody uses anymore because free DV certificates from Let's Encrypt are nearly as good and much easier to deal with.
Posted Dec 19, 2023 20:24 UTC (Tue)
by Wol (subscriber, #4433)
[Link]
"emerge firefox"? :-) :-)
Cheers,
Posted Dec 19, 2023 11:31 UTC (Tue)
by kleptog (subscriber, #1183)
[Link]
The problem is we have different groups of people trying to solve the same problem of trust. Suppose some European government has a complete digital infrastructure set up for their citizens to file taxes, manage health insurance, etc for example, and then Chrome decides to revoke the root cert. Then there is a Big Problem. We are talking about an identity scheme after all, break that and everything breaks. (This is not hypothetical, remember DigiNotar.)
The CA/B and browser makers don't trust the European governments to do the right thing. And the European governments don't trust the CA/B or browser makers to do the right thing. When people here say "the EU is trying to do an end run around the CA/B" what the policy makers hear is "these people want our digital infrastructure to be beholden to foreign actors who may not have our interests at heart".
Suppose the US government started leaning on Google to revoke the CA certificate of a European government, do you really think Google would resist? Arguments like "but the US government would never do that" don't fly in this case. Sovereign states are paranoid that way.
So the typical EU approach is to write it into a regulation since then at least on paper the problem is solved. It's of course completely unenforceable. Ideally all these groups would (gasp) talk to each other and figure out a way to make everyone happy. However, my understanding is that the CA/B has pretty much a "my way or the highway" approach. Classic government vs business actually.
Posted Dec 23, 2023 23:21 UTC (Sat)
by DanilaBerezin (guest, #168271)
[Link]
Posted Dec 14, 2023 6:53 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link] (30 responses)
He then claims it is impossible to encrypt emails because the recipient can forward the data unencrypted… uhm… and how does whatsapp prevent this instead? Last time I saw it, there was a button to share photos to other people…
A signature done by a 3rd party corporation like Signify is completely meaningless. Stop saying it solves anything else than pay their bills.
Also the whole post is on the website of a company that sells security… of course they would disagree to having security for free.
Posted Dec 14, 2023 9:29 UTC (Thu)
by Moarc (guest, #137864)
[Link] (1 responses)
umm, what? signify is a FLOSS utility developed by the OpenBSD project.
Posted Dec 14, 2023 10:09 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link]
Posted Dec 14, 2023 10:51 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (14 responses)
It's not that "the recipient can forward the data unencrypted"; it's that the default behaviour of e-mail clients with integrated PGP is to remove encryption if you add a recipient that you don't have keys for; other protocols avoid this because the clients have a way to get keys for any recipient they can send to, and therefore adding a new recipient first has your client do a key exchange with the recipient, before forwarding the data to them.
And that's the root of PGP's problems; the UX for using it sucks badly; which is why you're advised to use Free software alternatives like signify, Tarsnap, and Magic Wormhole.
Posted Dec 14, 2023 13:20 UTC (Thu)
by qyliss (subscriber, #131684)
[Link]
> The Tarsnap client source code is available so that you can see exactly how your data is protected; however, it is not distributed under an Open Source license.
Posted Dec 14, 2023 13:49 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link] (12 responses)
Posted Dec 14, 2023 14:16 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (11 responses)
What if your client is not set to encrypt everything? Will it warn you if you started by hitting reply to an encrypted mail, added someone to the CC list, and the person you added has no key available right now?
My experience is that e-mail clients not set to encrypt everything will silently fall back to plain text in that case.
Posted Dec 14, 2023 14:40 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link] (10 responses)
Posted Dec 14, 2023 15:20 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (2 responses)
But that then becomes painful in the current world, where a majority of my contacts do not use PGP - so I'd not turn on "encrypt by default" because that will train me to ignore the prompt.
Posted Dec 14, 2023 23:01 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link] (1 responses)
If your requirements negate themselves, yes, no solution can be found.
Posted Dec 15, 2023 10:54 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
No I'm not - I'm complaining that I can't have both of the following:
These are not in conflict - they are starting from different points (do I have previously encrypted content or not?). Other systems handle this by being purely encrypted, so there's never an issue with recipients for whom you don't have a key - in order to communicate with someone at all, you must have a key.
Posted Dec 14, 2023 19:15 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (6 responses)
* The web client or the underlying SMTP service? Both. Or, more accurately, the average user has no understanding of this question and cannot articulate the difference.
Posted Dec 14, 2023 23:05 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link] (5 responses)
It's very easy but it's also kinda pointless. At that point, use protonmail and you have e2e emails that might have a backdoor but hopefully do not. I see you very conveniently didn't mention protonmail, which would be the equivalent of the services you mentioned.
Posted Dec 15, 2023 1:03 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (4 responses)
Posted Dec 15, 2023 6:11 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (3 responses)
If we consider the average user usecase, they are getting it via the store…
Posted Dec 15, 2023 7:11 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Posted Dec 15, 2023 16:31 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (1 responses)
An apk that we can't verify because it isn't the same as the one the nerds get from the signal website or compile themselves.
Posted Dec 18, 2023 1:16 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
- send a bogus binary on first install and provide self-signed binaries into the future (I believe `adb` can do this, but so can the Android API[1]…though also subject to bogus Google deployments); or
Posted Dec 14, 2023 14:50 UTC (Thu)
by simon.d (guest, #168021)
[Link] (12 responses)
I tried hard to read that into the article, but I am not able to do that.
Posted Dec 14, 2023 23:06 UTC (Thu)
by LtWorf (subscriber, #124958)
[Link] (11 responses)
Posted Dec 15, 2023 1:46 UTC (Fri)
by simon.d (guest, #168021)
[Link] (10 responses)
Posted Dec 15, 2023 6:12 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (9 responses)
And it while it claims to use the signal protocol, we don't know.
Personally I think it does, but that it also implements convenient side channels that we aren't told about.
Posted Dec 15, 2023 7:12 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (8 responses)
Posted Dec 15, 2023 16:30 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (7 responses)
If you were for some reason going OT and talking about signal, the .apk you get from the store is not verifiable either. You need to sideload it manually, which is certainly no more user friendly than using encrypted emails.
Posted Dec 15, 2023 17:51 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (6 responses)
Posted Dec 15, 2023 18:55 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (5 responses)
Monitoring traffic can help but not so much unless you do it forever. How do you know the side channel isn't batched or triggered via some condition when a version check is performed, or when the server asks to activate it?
Google is perfectly able to send different binaries to different people. So the fact that they might have sent you a binary, in no way implies they sent me the same binary.
Posted Dec 15, 2023 19:12 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (4 responses)
Posted Dec 15, 2023 21:02 UTC (Fri)
by LtWorf (subscriber, #124958)
[Link] (3 responses)
With phones, they know my name and can push a specific malware update to my phone. With a linux distribution they can't do that, they have to push it to everyone as well.
It is possible of course, but hacking an entire linux distribution vs sending malware to a target whose name and phone number you have in your db aren't nearly at the same level of difficulty.
But I'm exhausted so, you win. You're right. Whatsapp is very very secure and completely trustworthy.
Posted Dec 15, 2023 21:24 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
How? How do you know your kernel hasn't been modified by your firmware to identify linear reads of the pgp binary to return the expected hash, but to introduce a backdoor when it's executed? I don't think this is realistic, but nor do I think it's realistic that Google is being compelled to ship backdoored versions of messaging apps to specific users.
> With a linux distribution they can't do that, they have to push it to everyone as well.
No, there's any number of ways you could be targeted.
> Whatsapp is very very secure and completely trustworthy.
I'm not going to make that claim. All I'll say is that there's no evidence that the end to end encryption in Whatsapp is backdoored.
Posted Dec 15, 2023 22:05 UTC (Fri)
by pizza (subscriber, #46)
[Link]
Sure, but it takes an order of magnitude more complexity -- you have to compromise the _entire_ distro's infrastructure, from the source code repositories to the package builders to the package signers to the public mirror infrastructure.
You'd have to be specifically redirected to a hostile mirror, which in turn has to have a single hostile package that was signed by the distro package signing keys, with matching repo metadata that was also properly signed. Of course, that presumes that you're even using the public mirror infrastructure to begin with; if not the complexity is even higher, with potentially requiring compromising your ISP and or ISP's transit provider to hikjack a specific IP.
In other words, to compromise GPG binaries on a specific linux box via the distribution's update process (as that aformentioned malware push to criminals' phones required) you'd need all the steps there, plus quite a few more.
Or you can try to attack it via other means. Stuxnet infamously used malware on usb sticks, after all.
Posted Dec 18, 2023 5:11 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
> I'm not going to make that claim. All I'll say is that there's no evidence that the end to end encryption in Whatsapp is backdoored.
I'm going to add to that slightly and say that even if in the future it is discovered that WhatsApp is backdoored (compelled by secret government order for example) that still doesn't change the fact that _today_ there is no evidence for it. A stopped clock being "right" twice a day doesn't make the clock _right_.
WhatsApp and Meta surely have to comply with legally issued court orders in any jurisdiction they operate in, which may well include metadata about communication even if it doesn't contain the communication itself due to E2EE. There is also the whole OS that any app runs on, which is what we've seen tons of evidence that intelligence services collect and use zero-days of the OS to access encrypted message. There is also the mechanism of having a court-ordered backdoor into the on-screen keyboard, which has been a suspected weakness of Signal for years when used in non-English speaking regions with wider variety of IME.
Posted Dec 14, 2023 4:04 UTC (Thu)
by anarcat (subscriber, #66354)
[Link] (2 responses)
This is an amazing piece of work, congratulations!
Posted Dec 14, 2023 22:07 UTC (Thu)
by dbnichol (subscriber, #39622)
[Link]
Posted Dec 18, 2023 23:24 UTC (Mon)
by dkg (subscriber, #55359)
[Link]
I've never seen such clear writing and systemic thinking about the protocol all set in one place -- i hope anyone using or contributing to OpenPGP will consult this guide going forward, and will refer to it when asking or answering questions during the "transmitting the lore" part of the work.
And, to the extent that it doesn't cover any given topic (either due to one of the sections that hasn't been fleshed out yet, or due to the impossibility of capturing all the nuance in one go), the authors are friendly and willing to receive and act on feedback.
Kudos to the team that is developing this work!
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
[2] Outside of national security apparatuses (and their targets)...
OpenPGP for application developers
* Lack of forward secrecy. No plausible path to introducing forward secrecy.
* Excessive overall complexity. Trying to do too many things, and doing them all poorly.
* Web of trust never worked and never will. No plausible alternative to centralized PKI. Some marginal utility if the parties can meet in person and exchange keys manually.
* You leak the fact that Alice sent a message to Bob on such-and-such date, and this is likely tied to Alice and Bob's real identities.
* In practice, most PGP messages are going to interact with GPG at some point, and GPG has a long track record of security issues.
OpenPGP for application developers
(But given the inherent complexity in a PFC system, I find it a hoot to see your very next complaint is....)
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
Reading between the lines of an English High Court ruling, it seems that the middleman that was "compromised" wasn't even Encrochat, but their hosting company:
OpenPGP for application developers
It appears that, in late 2019, the French authorities had discovered that an EncroChat server was located in Roubaix as a result of investigations underway at the Lille Regional Court. They were able to obtain images of the EncroChat servers in France, which were subsequently analysed.
A French and Dutch Joint Investigation Team (JIT)
...explained that they had developed a capability to obtain data from EncroChat devices which they were expecting to deploy, commencing activity on 10 March 2020. It was explained that the date of commencement of the activity was controlled exclusively by the JIT and that the activity would be undertaken worldwide, including handsets in the UK, regardless of whether the UK gave permission for the activity or not.
and
An implant within an application will be placed on all EncroChat devices worldwide. This will be placed on devices via an update from the update server in France...
which, obviously, requires write access to the server.
The French had all the necessary legal instruments in place to undertake the extraction of the material from the devices all over the world lawfully as a matter of French law.
The High Court ruling was about whether and how that evidence could be used in English and Welsh cases. There have been a number of serious cases since then where Encrochat downloads have been a key part of the evidence.
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
Wol
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
<SENDER_REF>THOMASBEALE</SENDER_REF>
<SENDER_TOKEN>3365036684924990967636964155485067452892657064412277449233566451980067029137
5477743162555038781857786811301836896402183278394149679519126465075124789484
1962540274750866321010289718780840929975434444110211339484547636662989613102
6272886578099380061449162975745808292853195012972919667815012019573381572474
6319778688021094455491760170713314346822118293171316896562131032203921626142
0916419461700553174275227674413636338054330520322647017497744533945155128753
5119233588535074595595068234379232475660316119234378796886503768490619000045
4319801716701311440995373529442862367744586741100832718698237699658516678736
7958993626775103953010292257404568170059105489066998351808210469238065619075
9861332298324389437438045362401440719711136869984232070112674053185038937178
4703382969500187413403716974561073736919839207223637998800755856407297223661
7110396094551271315468092496560072563559103081991604381084412636375681632636
5015620410898181603981512069385577398015982118581782843834221515976048873307
0222018633685270580199667385195111401085224441024341106753081887743691474093
1204717446966490927027555426340715883333092629980798764403249891651077929009
8876982463742956375027613293191719574238015971109099013862189800929533687773
6636025982941555345241444341373045673983128249228796208052455110863122576817
5307925046135083639351383257250252497667309622229703911040115174629140614392
1997075830713341819547129040894567050498642949081272470360884583091523520924
8045196352450587716187615643800091115522714867735193138178465939731033919839
1247123395251876238261135387865171744226234911447062903843505742548399357872
8378556853723909376844892449715806527396751971187106873319649824279821449944
7311390506038526416649791581139402349104279934844852733245608750381405208298
3614280903230814300653341091680303164440618289419234482654159581006346715062
1671528134790413907624262027364401979271092110091445632635307891845612089077
2372482756839421785346584505254228528801609715439285236359450710304191978654
3125265187554596041929966599435321104118984687832859388529338965412244819415
6211402849108237128621082519895941422148045820959001690653884937610250441770
1296774802362770772976643709888651468114701947962187906871563747470600049252
0451223321887687774127325460222990063093800060320650641829330849321416141080
5660734681028739095329462391869222076919350658783623832381897912437846434332
2279330208171770296981011691658348600973001266294628510961633570039222477993
4504091235867496481116664563640792130836612709018554270424862821041248319321
4995532569390687879219222505976958346916608564630355371805112773639747548485
1880132644627914728006554180710448239473517017289381367192692654198983226102
7339384610564462790326710592300304200498423089203490102705818082253545422907
3763870431271079215825197340443538065775816266801227969120941782617849976138
8770233655407424030788319184593245733128097835551264096555343837222562045180
5832031044939632644398558424371988467142671601782732056093967507188198357804
3161851297300669793890820619439188529688642058178449031383696287125401496392
6020413767381749428900754434412126760273313417224482745694724912575141054519
7473410852080109400130260917440364848297089260036294326006403084017248965214
6381611052942958617920600450230738019731569698917730425006241797450965835051
7101675683975445689195490607882759923052056129091874220770064471914958661283
3649673472582169237277852660642014532746502609104511236043517838615828884699
5744196909546223213452809150311239928983162938337397872291222558669272307507
9341436265259468631236969255119322869194149847398907524704875724433292239401
9121197571478353903605940461715525555208061352978487607815979652191145787268
6950328995335945571745979687723097806414156914235021770997528961679714004813
7618596119398900022187662176565995166377438393908409067315451467692128661853
1899480953509942132189806048058909083118927055319534887843833808044512581081
3012093514664551283123780007625168306833881406190667033836697748583233031255
1675716028819669389395202364050615268659231042662674269901807828871559507688
8022701173763594062553896327932025363395391687694248119992130852755849674297
8273600250603539265567026085682493356742692311281927863726477473769240282882
7867933659940712936309588787535103440817503293064795155896969420847827547707
4089681733030222153539427522154031172089076078854432286931762450766139647039
0698788357057812318058815396010365782622404931040489223653893467512868285772
3549426853707676535408525310171034962867389819981844492869820205296083623875
4503726920220137426575357670533609794887676554294539138939812541052897594003
9485623571345747061577161218224230150759545402677953393511696098548857192286
0418191625277945394737526273677827520272313903577312044494902926036964904851
4157906637444292236132297999422615180320615693358369126553766451078045897203
4625804915294342420408938444140675954119557682430618507597122864445387747250
7052818008685996841247865358357443555463898403621122251375563668643625395196
7433972371798247187619582107283546922431087641133454515472908057852709652581
9691055136808069110313554148450038678743055641375132947203442341171536802691
6211856712351555315688321511809857353701604031666811735529141268111133831982
1906536426488692828399107752047193697454998574776094907855010108566022811487
8242403809704249255684995041908008954822294124691925448991060986360890702522
4555164574759410427007356346902209194655891369214874694682582059573171715783
3241771118505430663162455511824437272322185300069078185566756813646570261574
0088701004098147418386108783630588753198356464011102566888631447008775843304
7937030346585649813080731557396858170123927099117448739148474436303968827868
7353872439492571777654462062266959179469115075180653288246652181906126610519
9156150001526025563337094657731332114755175973461257296918166923877577142615
0190195970324103382701996982746030124735391023592266899404435974235677830551
6968673405521157451095343812330563036975732417904887503443584091914250973970
5896673064939021557880784434472083464711073599708636094316668813932527134994
4832013900647025058310536471060754566780859558890974597741042784510999231331
3484283673578795846361221908092330712547420097150974492059494723034381681343
9307990662079749716717304752683848691952501742559305759400913970008534748005
2407734422737279462877957938933649764675057668700279317184044321803473577612
0489610878018912034296379230553914212985317668439788343463541094082992260476
7160562194667613119295010415502564256050656673774660813742144313897014538146
1774729241500261033032081255530974222939091935558190786372276143768952918539
0932360620159782500440609480921688746789553655685705522662832016583725311380
4108992734362233642108824811678464076727966782112885392540479191227651017598
9076926043334012221760494770424913951493169453817719051200702879929970073599
3806631432406435758708796744672286721973990892772026605422167360144646157247
5547767160547171552378014840053226694092186118383777340845624007579991092095
5702851690435319933776586128910496329002237384713149044370746356344904268577
6575624736271162647894431249714714139652686846756819653733767382968606410086
5788653055801003488896320570428445432842174658745273269942281284875875849643
9986868695110219387989344785267630574895443945474320729790653094315036457127
2607804159325347049030048969687750490158159140812158854418848340029982826503
3676949285427529449556937367188260717989575424252240126296125240551304141978
6685267347107545870359969188876188024006245687380093899978501620646456681531
0591212130089651190450263774186613915206223988475124834437196473515332649036
9903168574787862299111715118219801591021424548324159802323736591393805163807
6394728562918074982331962095793218794696736575476276983259069634909252407561
6224699028498723229809699663844082416495898884690180407632424189238415904816
8011017706183160756758564606771100000431453776306695173839360061014449685998
7060075296930177819862352047434861669441136117191219335952375929916761538530
6780246731795792616329932253333564861529071494775813285309013603079780081704
2684262621485409751093020570028811017953851677109942046190939751421400532339
3239971327056226995050061996880407882444511128187685402259011775947585666647
4561020168338537992837294647868498987109087254103290048914695868956464730896
6259025815217877945013258683779544802394984135615398657194470257980330430438
2289090751806848266278581498066925160786038762585210339272774489056065240259
9</SENDER_TOKEN>
<RECIPIENT_REF>WILLIAMTEACH</RECIPIENT_REF>
<TEXT>VxQCG4lj8+LxJV0wuLCnKgziIkOLutwamfdkg6xlKQa3cQ7yX8eTJFTWnh7g67un57P297n7PsG4
2CVad+pIB/4e9YjLPawqvYDh7iqx5TJ6wvIOF9+CEGlifAL/ttxNgZRO0aGb+COmOuQlsT/GjAxX
FfCiP9kqjg3rVpaAisBdLGcervNs9NODF/AJF8udmAxJiD8S+UQiP5w0ir6EXDuKBfBX6iaENaOm
ik3PB8+xcZYF2MEmy79ehYmmzMkwpkqOxSEYaySFwvy7Z5bXsb3TuKgaDJpsuKnG9SW67DThn95u
lP93W7Pw0Mwhzj2sMg9ToIqjDqXWEnkgpNJxLkuvoVq1+dE4FCEgqjtsfa6o8FSU8hTHA+ald5iw
M1RmfCMAdSi+xLqh7rqYBmHzN1s0/QR0OIQDLCF9t+/BKWZB0BfOxZc4
</TEXT>
</MESSAGE>
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
Wol
OpenPGP for application developers
OpenPGP for application developers
Wol
OpenPGP for application developers
Wol
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
Well, that and "If we turn out to be lying, then our whole business goes up in smoke." See for example the CA/B process
OpenPGP for application developers
Wol
OpenPGP for application developers
It may not be the simplest thing for most users, but if a user can modify the source of the browser, it'll be easy to delete those root certs.
OpenPGP for application developers
Wol
OpenPGP for application developers
PGP specific use case
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
** Yes, they do things that you probably are horrified by (e.g. top-posting, whatever Gmail is doing with whitespace these days, HTML, etc.). The average user neither knows nor cares about any of those things.
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
- send an older Signal-signed binary with a known vulnerability that can be used.
OpenPGP for application developers
The article recommends to use "Signal-protocol-based" messengers. WhatsApp is not even the first example. Signal has client and server open-source, so you can setup your own server and use it.
Or you can use a server not in your control (as most people do with e-mail). You can use the signal-based Session Messenger for a decentralized solution.
OpenPGP for application developers
OpenPGP for application developers
The site recommends to use a signal-protocol based secure messengers. So the solution is not to use WhatsApp, the solution is to use a signal-protocol based secure messenger. (where WhatsApp is an example).
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
OpenPGP for application developers
> No, there's any number of ways you could be targeted.
OpenPGP for application developers
I've been using PGP for decades and even wrote software that interfaces with GnuPG, and this is the best documentation I have ever seen describing the OpenPGP ecosystem.
OpenPGP for application developers
OpenPGP for application developers
I agree with this sentiment wholeheartedly! the OpenPGP ecosystem has (like many complex ecosystems) a rather complicated set of terms, practices, and expectations that most practitioners treat as a sort of "lore" gathered from active participation and use rather than explicitly documented aspects of the collective project.
OpenPGP for application developers