Rpgp: Pure Rust implementation of OpenPGP
github.com
github.com
Is it really because trust on first use is good enough for most cases? Or is email somehow so much different than chat? Or was PGP the proof-of-concept, and current e2e encrypted platforms are the v1.0? Or all of the above? Did I miss anything important?
i.e. WhatsApp and Signal care about UX and mainstream adoption. Nothing like that for email has tried to do PGP.
More generally, the OpenPGP world is in a bit of a double-bind: they can either fix things by breaking compatibility (at which point someone can reasonably observe that there's no good reason not to ditch OpenPGP entirely), or retain compatibility and accept that OpenPGP will never get much better than RFC 4880 and whatever smattering of drafts the GnuPG maintainers agree to implement. One way essentially results in an entirely different tool/standard that happens to be wearing PGP's skin; the other means keeping around misuse-prone and outright broken cryptographic primitives (and bad formats to boot).
(To answer your actual question: email is just a bad substrate for attempting E2EE messaging. Latacora has a great explainer post on why[1]. TOFU is a mostly adjacent concern; trust/identity negotiation is hard, but the thing that makes WhatsApp, Signal, etc. actually work is that they eliminate manual key management and make cryptographic right choices for the user, rather than expecting the user to hold the tool correctly. In other words: they're misuse-resistant, where PGP as an ecosystem has historically not been.)
[1]: https://www.latacora.com/blog/2020/02/19/stop-using-encrypte...
(Signal and WhatsApp also have forward secrecy properties that PGP, as an ecosystem, is nowhere close to providing. PGP very much still operates under the "one master key that you must never ever lose or disclose" paradigm.)
(But note: absent something like that, it in fact is possible for Signal to prove that you’re communicating with the same identity you initiated with. That’s the whole point of authenticated key agreement, which is not something that PGP can natively perform.)
Is that not tofu, which is easy in many crypto systems?
In other words: you always need to perform OOB identity verification, regardless of your messaging system of choice. There is no way around this; it’s a fundamentally social and UX problem rather than a cryptographic one. But this doesn’t change the fact that, once you have a trusted identity, Signal’s MITM protections are significantly stronger than PGP’s (including forward secrecy, as noted before).
Web-of-trust alleviates that, to some extent.
(I think WoTs can solve these problems. But PGP's implementation has been so far the most ambitious tried by a semi-large audience, and it didn't hold up. We need a better starting point.)
This attack will be noticeable: there will be a message warning the user that the cryptographic keys have changed on the other end. You know what else generates these warnings? Reinstalling WhatsApp, switching phones... They're basically noise to users by now due to alarm fatigue. How many users even know what that this key stuff means anyway? How many people even use the built-in key verification function which consists of just scanning a QR code? I've yet to meet a single person who cares about any of this stuff.
The assumption underlying much of the post is that PGP is only used in offline, stateless applications. This would make the arguments stronger, except that it isn’t true[1].
It's really OCFB-MDC. It's only a authenticated mode when the two things are used together (like GCM). It doesn't provide protection of associated data (the AD part of AEAD) but that isn't something that seems to be potentially useful for the stuff that the OpenPGP standard is used for. I don't know what "true AEAD" means in this context. As a user I only care that the OCFB-MDC mode is actually secure. I am not interested in any philosophical aspects.
The stuff about offline stateless applications only adds to the argument. A version of OCFB-MDC could be used, for say, TLS and would be expected to be secure.
It isn't sensible to assert this, because people use OpenPGP in all kinds of crazy ways. One of the recurring headaches in applied cryptographic engineering is discovering that people do, in fact, attempt to use PGP for instant messaging (per above), as a TLS certificate delivery mechanism, etc. These are contexts where the use of an AEAD is frequently appropriate.
> As a user I only care that the OCFB-MDC mode is actually secure.
In practice, it has not been[1]. PGP's decision to use MDC instead of a real MAC is a classic example of home-rolled primitives being conceptually algebraically sound but broken in user settings. The solution here is simple: OpenPGP is not special, and should use a MAC or AEAD mode like everyone else does. It also shouldn't release the plaintext until the authentication tag is actually validated, which was another profound historic breakage with MDC.
[1]: https://mailarchive.ietf.org/arch/msg/openpgp/w4i30aLplh91iw...
>PGP's decision to use MDC instead of a real MAC...
The MDC can be interpreted as a MAC. The hash is first seeded with a MAC key (the "random block"). So a boring old hash MAC. SHA-1 is vulnerable to length extension attacks but that is not an issue here as the attacker never gets access to the state of the hash (everything is encrypted). I guess this could be considered an advantage of MAC then encrypt. The only property the hash requires is that the MAC key will be propagated to the check value in such a way that it is indistinguishable from random. So SHA-1 is wild overkill here.
The challenge is that there’s no money to be made so you’d need a non profit like Signal to do it to disrupt that industry.
For example, you could run a proxy server to deliver the messages between parties. So if you’re emailing someone, the browser extension changes the address to be a server you control, sends you the encrypted email that has everything meaningful encrypted, you decrypt the part your able to (ie the intended receiver) and forward that.
As far as either email server is concerned, your email server is sending out and receiving encrypted emails but there’s no metadata to connect anyone. The key handling uses your access to the email account to validate access same as signal uses the phone number.
That seems like a pretty close system to how Signal works and I don’t see anything meaningfully different. If you do, can you actually elaborate? I don’t feel like the link you pointed me answers why my proposal would be larping security since the security and threat model feels very similar to Signal.
Here are some choice quotes I pulled out of that link and why I have problems with the claims made:
> Searchable archives are too useful to sacrifice, but for secure messaging, archival is an unreasonable default. Secure messaging systems make arrangements for “disappearing messages”.
Signal and most apps except Snapchat (which isn’t e2e afaik) don’t archive by default. But yes, it is true that having encrypted web mail and search are incompatible whereas messaging apps store the data locally and thus can provide search. You’d need a dedicated client that could store all the encrypted messages locally but people aren’t as used to for that.
> Some email clients have obscure tools for automatically pruning archives, but there’s no way for me to reliably signal to a counterparty that the message I’m about to send should not be retained for more than 30 minutes.
Talk about security LARPing. Once the message is sent you’ve lost all control of it. Your just following social contracts that the app honors the request and the user is using an unmodified app.
> No matter how good a job one does securing their own data, their emails are always at the mercy of the least secure person they’ve sent them to.
Also true for messaging apps
You could just email each other your Signal ids at that point. It's no longer the email everyone thinks of as email.
It felt a small team or a single person project. There was a cat and mouse game being played against Gmail interface changes, with the encryption being broken every now and then. It required me, a random user, to trust the extension developer(s) with my Gmail and gpg keys. I had fear of having an xz backdoor situation compromising my Gmail account and gpg keys.
And for this extension to succeed I also had to convince all my Gmail friends and contacts to use it, and convincing them to trust the developers of the extension as I had done.
While I felt confident that the extension was perfectly safe I didn't dare to convince my family and friends to use it because (a) I could not guarantee that the extension wouldn't be compromised in the future and (b) the chance of the extension being broken in the future due to a Gmail UI change was close to 100%. Also the more users the extension had the higher the chances for someone to attempt to infiltrate to attempt a backdoor...
If I recall correctly, eventually the developer got tired of the Gmail UI changes and increasing demands of users and moved on, stopping the development.
Anyone with time could try to develop such an extension, but there were drawbacks back in the day...
Nothing stops you from implementing a similar mechanism based on email addresses.
And that is where they get their usability
They are 3 particular paths that aren’t in any way open to most attackers but will work here.
Saying it impacts all applications isn’t wrong but it’s also not relevant to what was asked.
If whatever the hell you are doing requires a threat model where the NSA is interested in finding out who you are talking with and what you are saying the original comment of signal is inappropriate is 100% accurate.
It’s a criticism of the platform, not applications running on it.
Yes, phone operating systems are more modern, and implement: sandboxing, hardware security, MAC, app permissions, etc. That’s why they do less. In this category, I would use iPadOS in lockdown mode.
But a phone is a device for the every day use of an average user. It’s not designed to be a security device to protect people against targeted attacks. If your threat model is a state actor, you might be better off with a desktop. Phones have phone numbers and take unauthenticated input from the external sources (messages). There is an opaque baseband chip. The threat model in which they are secure is skewed in favor of the phone provider: essentially you rent their device, and share your information. Phones communicate information about user such as the location, and might conveniently backup users data to the external servers by default. There is limited app choice. You can’t inspect, select and customize a phone OS. On the other hand, I can cherry pick a desktop OS, even build one selecting components, see, monitor and control the software, and run it on hardware from a source I trust.
I'm not saying this to convince you, just to establish that we are definitely talking about the same thing, and I am definitely not being flippant.
So for instance, if you are using signal to do an outreach and support operation for a human rights group operating in China, it might be reasonable to assume that some Chinese intelligence orgs can view your plaintext. The strategy would then be to not transmit any information that would allow a decisive action against the group. The opportunity cost of revealing the surveillance has to be greater than the utility of acting on the intelligence. But obviously this would compromise the scope of assistance you could provide.
And the risk is iffy, for a few reasons that I've thought of since seeing your response:
1) PGP key exchange has the same problems when done over the network. Doing foreign outreach via PGP has the same problems.
2) I don't know of any examples of Signal MITM attacks stemming from weak key exchange. Worse, I don't actually know how key exchange works on signal
4) Key exchange problems are more of a universal nitpick against all crypto systems, not a full compromise
I'd be curious about your feedback - even if it's a chastisement.
I am also curious if you feel signal has any REAL issues which keep you up at night, if not key exchange.
On individual level, if you have being targeted or use a tool with 0day then you lost before you even know that there was a game.
PGP could have a phone app that will do easy encryption, such as protonmail.
Amazing that you consider a proprietary thing like whatsapp remotely secure. For all we know it's backdoored.
And signal… not available on fdroid… thus mostly installed via apple/google… how difficult would it be to push a backdoored update to selected individuals?
GPG is more secure
They both use a centralized, authority for identification and key sharing, sidestepping the hardest part entirely. Also, they are their own protocol and as such you don't suffer the encrypted/plain-text-only email dichotomy, sidestepping another pain point.
When you don't care about the decentralized nature of email and can force everything to be encrypted, then the problem becomes much easier.
IMO, the way GPG was done killed what could have been a decent ecosystem. It's a combination of two factors:
1. Don't roll your own crypto.
2. The available code (gpg) is a colossal pain to use.
So for instance, how does something like KMail deal with gpg? There's no libgpg originally. There's just the gpg tool, so you've got to call it as a sub-process, and it really sucks:
1. You have to deal with process management, multiple filehandles, text parsing, non-trivial interactions, etc.
2. It's slow. You pay startup costs every single time. This is a huge problem on something interactive like a mail client, and it's dependent on things like the amount of keys in the gpg store.
3. gpg has very specific ideas about how it wants to be used, and not everything fits.
Say that you oh, want to do some stats on GPG keys. There's no libgpg to just read an .asc file and get the list of signatures from that, no. You have to call gpg, feed it the key, parse the result. For some things you might actually have to have gpg import the key first. Manage a fake home dir for GPG. Deal with the horrible performance as the keystore grows. A million keys at a gpg invocation per second is going to be around 2 weeks.
Unfortunately it's only now that gpg is effectively dead that the problem started to get fixed.
Also, at this point GPG is effectively a legacy technology anyway. Modern cryptographic thought considers GPG to be a terrible idea for a whole bunch of reasons that are deeply built into it, so the only solution for that is throwing it out.
I've played around with designing a higher level library to OpenPGP once (https://pypi.org/project/pysequoia/) and personally I think it yields more readable, faster and secure code.
Sounds like a great way to transition things in a saner direction. You know it will be bug-for-bug compatible with calling the gpg-binary. Having one blessed text-parser with a lot of eyes on it is much better than everyone rolling their own. Getting people used to depending on a library instead of shelling out also means it becomes possible to move the library to independent implementations.
The standard way to use GPG is via the gpgme librairie which then communicate with the Assuan protocol to the gpg deamon. Gpgme has official bindings to C++, Qt and python. In KMail we use the Qt bindings and it works fine.
Nice work :) Looking forward to seeing further improvements to it, it's still got a few rough edges, but otherwise I really like it.
> The standard way to use GPG is via the gpgme librairie which then communicate with the Assuan protocol to the gpg deamon.
Yeah, but all GPGme does is calling the gpg binary and presenting a more palatable interface to applications.
That solves the problem as far as the API goes, but performance is still terrible for some uses, and it's still liable to run into all kinds of weird problems in edge cases. But at least for something like mail clients it seems to work well enough.
And I believe these days you can use SSH keys for signing commits as well.
This is exactly the meme I would try to propagate if I had backdoored every popular crypto implementation. More people should roll their own crypto so they can stumble and learn and eventually get good at it.
This would only work if it were always obvious when your implementation is unsecure, which is not the case.
If you want to roll your crypto, become a cryptographer first. That sounds circular, but isn’t.
@wiktor-k is working on a tool to use rpgp to provide a simple solution to work with smartcards
Overall I'm pretty happy with the codebase.
The PoC for using cards in git is in https://github.com/wiktor-k/monkeybagel (excuse the silly name ;).
On Windows and Mac it binds to system libraries. On Linux it works with pcsclite.
Btw I'm not aware of any tooling that's used by Sequoia, rather wrappers that use Sequoia and pcsc crate.
This is the same algorithm used by git.
There are higher level implementations that use the dates on signatures to straight out reject sha1 material, but that gives only a limited protection.
Rpgp is much smaller but also very flexible. It's easy to adjust to more specific needs. It's also associated with RustCrypto project and with Rust in general.
For example to add rpgp to your project you just do "cargo add pgp". To use Sequoia "properly" you need this multiline setup which depends on whether your crate is a "leaf" crate or not: https://gitlab.com/sequoia-pgp/sequoia/-/tree/main/openpgp?r...
Another example: Sequoia is against rustfmt. This makes it harder to contribute.
On the other side rpgp is much more barebones and instead of docs you need to read the source (which is rather readable).
Both of them would benefit from a high level API, so that the users wouldn't have to work with types such as ValidUserAttributeAmalgamationIter (https://docs.rs/sequoia-openpgp/latest/sequoia_openpgp/cert/...).
Full disclaimer: I've worked 3 years on core Sequoia and I'm kind of involved in the OpenPGP protocol: https://github.com/wiktor-k
I could be missing something here, but I think this is vulnerable to DO'1985, a/k/a Desmedt-Odlyzko:
https://github.com/rpgp/rpgp/blob/8e67756ebce780c91b8c2ffc7d...
In particular, in the presence of an insufficiently wide hash, the absence of padding here means that RSA signature validation is not secure under EUF-CMA. Matt Green has a great post on why and when EUF-CMA matters[1].
(This isn't necessarily this implementation's fault, since PGP seemingly (!) encourages the stripping of padding from signatures. But I can't find another source for whether this is actually encouraged by OpenPGP, or whether implementations just widely allow it.)
[1]: https://blog.cryptographyengineering.com/euf-cma-and-suf-cma...
(Looks like the IncludeSec folks did a decent job in 2019. Hi Eric!)
However, I misread this: I thought the padding was being done on the cleartext signing side, but this is padding of the signature itself. So there's some malleability here, but it isn't susceptible to DO'1985. I'll update my top-level comment.
Is Rpgp emitting any new block cipher modes or generating keys that might cause such emission in the future? The risk here is a sort of incompatibility nightmare where decryption becomes a crap shoot.
My article on this mess:
https://articles.59.ca/doku.php?id=pgpfan:schism
[1] https://wiki.archlinux.org/title/GnuPG#Disable_unsupported_A...
The tl;dr is that GnuPG basically forked OpenPGP into https://librepgp.org/
Do note that sequoia and rpgp are different in many aspects so the licensing is just one thing.
https://deps.rs/repo/github/rpgp/rpgp#vulnerabilities
There is a reason why crypto primitives handling key material -- especially RSA and AES -- are not written in higher-level languages.
EDIT: Given this attack was also applied to OpenSSL, amongst many others this high level language comment seems doubly odd/dubious
EDIT2: another rust TLS implementation was among only 3 that was initially verified to be not vulnerable as well..
Yes, that's exactly what I'm stating.
Have a look at openssl, boringssl, nspr, etc. They all implement the core modular arithmetic for RSA and the s-box table for AES using assembly language. There is no reliable way to prevent a C compiler from "optimizing" your constant-time code into non-constant-time code.
another rust TLS implementation
rustls uses assembler (from boringssl) for these routines. It is not 100% rust, and that's a good thing.