"The sequoia-openpgp crate (Rust’s terminology for a library) is a low-level, policy-free OpenPGP implementation. Our goal was to implement all of RFC 4880, and provide an API that can be used to access and modify pretty much everything, but is simultaneously secure by default."
This is pretty exciting. Hope this gives the OpenPGP ecosystem a long needed push and more attention!
"Sequoia was started 3.5 years ago by Justus Winter, Kai Michaelis and me, Neal Walfield. Prior to working on Sequoia, the three of us had worked together at g10code on GnuPG."
I’d recommend that people avoid PGP and use modern cryptography. Eg. AGE, It uses far less and simpler code, so it can be audited. PGP is a complicated old mess.
OpenPGP is a standard, and a very flexible one. Not all implementations need to support all features. You cannot compare it to something like AGE, which is simply a single implementation without any effort to turn it into a standard about anything, nor the goal to support various use cases. We could go on talking about the differences of approach and the benefits and drawbacks of standardization, flexiblity, libraries vs. end-user applications etc, but that's been discussed times and times again here and elsewhere. There is simply no alternative to OpenPGP the standard and its efforts. Or can you point us at one?
Have you looked at the OpenPGP spec? I find it pretty readable, and you will quickly see how it cannot be compared to any single application.
I understand that AGE also has a "spec". It is limited to a single use case, encryption. No signatures, no certifications, no thoughts on key discovery or trust, etc etc.
The track record of cryptographic standards is one of pretty much unbroken failure; it's like the cryptography engineering version of "I'm from the government and I'm here to help".
It get worse when you take a close look at the standards process and see how standards bodies metabolize input from actual cryptographers. For a good time, check out how the IETF did with Phil Rogaway and IPSEC.
It certainly sounds like you're saying that cryptography needs to be brittle to be modern, which of course will find a lot of valid disagreement.
There's no way that any non-flexible cryptography can ever stay modern if it doesn't accommodate for various key sizes and algorithms. If for no other reason, because we continue to see more and more compute power that makes brute forcing smaller or weaker keys more feasible.
The way to accommodate a new key size or algorithm is to say “v2 of the protocol will use $key_size and $cipher, and will not use $old_key_size or $old_cipher. Upgrade to this version due to $reason_old_setup_is_obsolete”. A casual observation of history will find that attempting to build negotiation of security features into a protocol is akin to opting in to a fun, optional class of major security vulnerability. For reference: SSL/TLS, GPG.
Not necessarily. You can also tie algorithms to keys. For example, if you want to verify a signature, it’s perfectly reasonable for the public key to actually be (algorithm, private key as defined by that algorithm). What you don’t want to do is put the algorithm in a message that is potentially controlled by an attacker.
The things you mention are causes of catastrophic security failures, not mitigations. 'Algorithm agility' (and related) is the source downgrade attacks, software that relies on cryptography tends to get broken computationally only after years of warnings about unsafe algorithms that are ignored, more often than not, due to over-reliance on standards both formal and de-facto.
You will find disagreement only if you deliberately choose words like "brittle". The word you want is "simple". Crypto protocols need to be simple, to reduce attack surfaces.
"Flexible" protocols are the ones that are actually "brittle" -this is where the use of metaphorical language breaks down. "Flexibility" actually just introduces more places to break.
It is by now well accepted that modern crypto protocols should, in fact, be simple, and you will NOT find much disagreement with this.
Sadly age is only tackling one of the easier parts of gnupg, encrypting files. Implying age replaces gnupg is overselling it.
We don't have any good alternatives for a web-of-trust (or something akin) where we can sign files or attest trust to some identity. Signify does parts of this, but lacks the trust aspects which makes you establish convoluted key distribution schemes to ensure you have future signing keys lined up.
There isn't any good replacements for F/OSS developers that needs to have some from of signatures between them. Say replace linux distributions usage of signatures to form some network of developer trust.
Which is why most distributions and other projects has moved to WKDs for key discovery. I don't think this is a good argument though as there are alternatives, even though they don't work super well at the moment.
> Which is why most distributions and other projects has moved to WKDs for key discovery.
Yeah, WKD is a first-class citizen in GnuPG. Creating signatures with "--sender $EMAIL" embeds e-mail in the signature and then gpg --auto-key-retrieve --verify will fetch the key via WKD without the need to touch keyservers.
Which makes the problem harder to solve. But this isn't an argument against the functionality though? It's still something we need if the community wants to move away from GnuPG.
What are the alternatives? PKCS7? I don't see that being less complicated then gnupg when it comes to usage. I think Void Linux is using this though, however you are still stuck without a proper way to assign trust.
Are you claiming that the Sequoia implementation of the OpenPGP standard is a "complicated old mess"? Because the OpenPGP standard (RFC 4880) isn't really all that complicated. A significant portion of is a bit by bit description of the key format.
At any rate, age is hardly any sort of replacement for OpenPGP. It is really only suitable for the case where you want to encrypt something like a backup and not bother to sign it. I am not really sure that it is superior even for that niche case. Most people would want to know a backup is corrupt before they started the restore, not partway through it.
> Most people would want to know a backup is corrupt before they started the restore, not partway through it.
Yes, which often makes OpenPGP a bad choice, because of how it has to authenticate things (requiring multiple passes). Many implementations of OpenPGP will happily release unauthenticated plaintext to the caller (and then fail at the end when the MAC fails- too late if you piped that to tar!) - there isn't an efficient way to do better than this with OpenPGP, because...well, it isn't very good.
> Any kind of signing (which is not a tooling problem, but a trust and key distribution problem, and to the extent that tools matter you should just use signify/minisign, and for keys we should probably use SSH ones)
Yeah, they could implement it, but why not keep the utilities small and specific to a use case. You can shasum over the backup and sign it if that's what you want.
Despite what the few naysayers in this thread would like to have you believe, there is a growing number of projects that rely on OpenPGP for security. Having a modern library for working with them is a giant plus no matter how you spin it.
A big thank you to everyone who worked to get sequoia this far.
tl;dr: PGP is absurdly complex, mired in backwards compatibility with broken crypto algorithms, and relies on long-term secrets with no forward secrecy.
In this very blog post, Sequoia PGP explains that they continue to support SHA-1, which was broken in 2005, for backwards compatibility reasons. They've added some code to mitigate the damage (introducing more complexity); they hope to turn off SHA-1 in 2023.
Cool. In the meantime, don't use PGP, not even Sequoia PGP. Use Signal to transfer messages and files. Use full-disk encryption for encrypting backups. Use Minisign to sign packages. Use libsodium for encrypting app data.
EDIT: This post is currently at -3 downvotes without comment, presumably from folks who think SHA-1 is just fine and that I'm overstating the case. I ask you to just read the link I posted and explain why you think PGP is good, actually, despite its terrible reputation among professional cryptographers and security professionals.
"We can’t say this more clearly or often enough: you can have backwards compatibility with the 1990s or you can have sound cryptography; you can’t have both."
You tell people not to use PGP, then recommend using Signal.
Signal requires a phone number and phone to sign up. The Signal backend server is run by Signal Messenger LLC. As far as I understand, you can't run your own backend server, there's some restriction there.
Signal's encryption is open and audited/auditable, and is convenient however it's not widely implemented in a public manner (Whatsapp and some other sites apparently use it; have consulted with Signal.)
I know PGP has flaws, the other replyee posted a link even.
But in less than 5 minutes, for free, and without violating my privacy to captchas or barbaric service terms, I can:
- Sign up for a brand new email address from a privacy respective service, on (almost) any device/system
- Generate a PGP keypair on (almost) any device/system
- Share the pubkey with a receiver
- Instantly send encrypted content
Is it more inconvenient than installing Signal? Yes, but it's far more flexible.
And I agree with the other replyee, this reply sounds more like a dislike of SHA-1, which is fine, rather than "don't use PGP".
Anyway, yes everyone who uses proprietary or anti-user messaging platforms should move to Signal/Matrix.
* The encrypted emails you send will transmit the headers in plaintext, including the sender, the recipient, and the subject line (which is message content!)
* Anyone who replies to your email unencrypted (which is the default way to reply, because email is insecure by default) will leak not just their own message but your encrypted message as well
* Every archived message will eventually leak
PGP offers you more control over the infrastructure, which might be valuable to you, but that control comes at a cost of reduced security. That's not an appropriate tradeoff for anyone who actually needs to send a secure message.
since when does Signal support emails? Sorry but a chat application is no replacement for async messaging.
> * Anyone who replies to your email unencrypted (which is the default way to reply, because email is insecure by default) will leak not just their own message but your encrypted message as well
This is major bullshit as they would have to know how to setup encryption to be able to decrypt your message in the first place, and all email clients I know will default to making the reply encrypted if the first message was encrypted in the first place.
> Every archived message will eventually leak
Even if that were remotely true, and it's not, the point is that you are able to TRANSMIT it over email in a safe way regardless of which provider you use. Archiving is besides the point.
> Signal isn't just more convenient; it's also more secure than your PGP encrypted emails.
Sure, but person to person email is not the only or even primary (for me) use case for GPG/PGP encryption.
The second line of the linked article says: " ... and a program to verify detached signatures geared towards software distribution systems called sqv." - a use case for which Signal is completely useless.
Signal is great for what it does, so long as you're prepared to accept it's current "needs to use real phone numbers and spams your Signal signup to everyone with your phone number in their contact list" behaviour. But keep in mind those are thew tradeoffs it's making for key distribution (and not everybody considers them to be "the right" tradeoffs). PGP/GPG ket distribution is a complete mess, which is why it's such a poor thing for cold-call person to person encrypted messages (even ignoring all the unencrypted metadata issues), BUT there's no way for me to use Signal in a bunch of scripts mailing database backups from servers, or to send intrusion detection notification emails, or to verify software repo downloads. Those are all areas where PGPs key distribution nightmare are not problems, and where PGP's "old school" long lasting keys are less of a problem. And there's _lots_ of those kinds of things in the world using PGP right now. new clean PGP implementations are a good thing for those - even though I'm not about to get all 1994 again and start emailing my friends using PGP...
Come on, it's true that sender, recepient, and time is valuable metadata that you may wish to obscure depending on one's security context, but if you are leaking sensitive information in the subject line of your pgp-encrypted emails that's on you... Why not just encrypt the subject?
The link you've given is good, but I think it misses two major aspects that the suggested alternatives don't deal with: identity management+verification and ease of key management.
The former being something entire countries are struggling with, how do we know the correct person is actually receiving the content, how can I be sure? WoT, PKI, whatever. You fail this, the rest is in practice IMHO less than useless. There's things like https://keybase.io that did try to solve this to a reasonable extent, PGP but more modern. It looked hopeful, but Zoom seems to only keep it on life support. Maybe someone will continue, anyways, I digress.
The second aspect is IMHO what determines how usable it is for a single person over long period of time. Maintaining backups of minisig keys, chat keys (or even not being able to do so), file encryption keys is difficult to say the least. It's unlikely you'll even be able to use a HSM for your secrets like a YubiKey. The same negatives listed against PGP apply to other systems suggested in the article. For example how do I communicate to people sending me encrypted messages that I lost and migrated to a new key/subkey? It's a very hairy problem.
(This reminds me, does anyone here know how to get PGP paper keys that use only english words e.g. "brunch pineapple house crow ..."? And does anyone know why we aren't using english words to compare PGP key IDs yet?)
I agree with a lot what the article lists, but the alternatives suggested really aren't compelling when looking at the actual problem. Judging based on the market share, I think I'm not the only one that thinks so.
> (This reminds me, does anyone here know how to get PGP paper keys that use only english words e.g. "brunch pineapple house crow ..."? And does anyone know why we aren't using english words to compare PGP key IDs yet?)
PGP invented that, and if you use actual PGP it will tell you your key fingerprint in English words, using https://en.wikipedia.org/wiki/PGP_word_list . Someone submitted a patch to GPG to do the same, but it got rejected for being non-localisable and bikeshedded to death.
> There's things like https://keybase.io that did try to solve this to a reasonable extent, PGP but more modern. It looked hopeful, but Zoom seems to only keep it on life support. Maybe someone will continue
It seems there's already Keybase like solution using OpenPGP only (no centralized infrastructure needed): https://keyoxide.org/
Interesting, cool to see someone building a similar service to Keybase's account proofs. Hopefully they'll also build something like Keybase's proof integration https://book.keybase.io/guides/proof-integration-guide as well.
If you have any suggestions as to which E2E (group) messaging+fileshare+git platform I could use as a replacement for Keybase I'm all ears.
As far as I've seen the proof integration is used only for Mastodon insurances and Keyoxide supports all of them by default: no need to ask for permission, no weird conditions to enter like, instance has to be bigger than N people.
I see this as a way to control who gets into Keybase. A perfect example of centralized control. The idea of programmable proofs looks good though.
> If you have any suggestions as to which E2E (group) messaging+fileshare+git platform I could use as a replacement for Keybase I'm all ears.
Sadly I won't help you with that. There are a number of services that want to eat Keybase's cake now but neither of them hits all points on my scale. So I'm using mostly several different services to get a semblance of the Keybase experience.
Yep, that's what I'm looking for, but for PGP/GPG. I'd like to avoid homebrew key recovery schemes because I don't want it to become a pain to recover.
It seems it is mandatory to post a link to "The PGP Problem" whenever anyone as much as mentions PGP. To save repetition, here is the link to my critique of that particular anti-PGP rant:
You've misunderstood a lot of Latacora's critique, but I think the most important point you've misunderstood is "negotiation."
> PGP does not do negotiation. It can't. PGP supports asynchronous store and forward applications. It works over a one way channel. Your cipher, digest, and compression preferences come along with your public key They are signed and so are protected by the base cryptographic system. An adversary would have to break the cryptography to modify your preferences.
> I do not agree that compatibility is a bad thing. PGP is actually a good example of how to deal with backwards compatibility in a good way.
"Negotiation" here doesn't mean a synchronous back-and-forth conversation. "Negotiation" in this case means, "if you're not sending me the most secure version, I'll just accept a somewhat less secure version."
PGP encrypted messages are "take it or leave it," but that doesn't mean that PGP doesn't do negotiation. Instead, it means that the PGP implementations decide how much insecurity to accept in favor of backwards compatibility.
Here, in the blog post linked at the top of this page, Sequoia moans that they can't bring themselves to turn off SHA-1 because Debian developers use it. They're accepting a less-secure implementation for backwards compatibility. It's right there in TFA.
I'll tell you what: instead of "don't use PGP," how about "Don't use SHA-1 and don't use any tool that accepts SHA-1 by default." Today, in 2020, that means "don't use GPG, and don't use Sequoia PGP" and I'm confident that it means "don't use PGP ever again," but you and I don't have to agree on that.
The fact that you can change the defaults to be more secure and less backwards compatible doesn't make PGP safe to use. It's dangerous by default. Don't use it, and don't advocate that others use it, until PGP is secure by default (in other words, never).
The other thing you've misunderstood is the problem with long-term keys.
> Most people prefer to keep their identity indefinitely. That is why, say, the Signal protocol also has a “practically-forever root key tied to their identity”. It is inherent to the problem.
No. Long-term public identifiers are indeed, desirable, but PGP's public identifiers are paired with secret keys. Tying your identity to your public key means that you can't change your secret key unless you change your public identifier as well. (In Signal terms, that would be like saying that you can't rotate your secret key without changing your public phone number, which would be absurd.)
>I'll tell you what: instead of "don't use PGP," how about "Don't use SHA-1 and don't use any tool that accepts SHA-1 by default."
SHA-1 is only broken for collisions. So far the best anyone has come up with for an attack on the SHA-1 in PGP is the mostly impractical Shambles attack on the PGP web of trust. This has been fixed in the implementations. When and if someone can demonstrate a practical attack using SHA-1 then more measures will be taken. This stuff is a little more complicated than just identifying particular hash methods in the list of features. This sort of thing is inherent in a long term encryption standard. You can't just randomly break things because you have a bad feeling about something.
>...but PGP's public identifiers are paired with secret keys.
In exactly the same way that, say, signal links its long term private identity key to public identifiers (your phone number). The problem is inherent in using public key cryptography for messaging. Most PGP implementations identify where that private key is kept and allow the user to protect it with a strong passphrase. That is opposed to how Signal depends on whatever security the device can provide to a key hidden somewhere on the device.
This is going to be my last reply to you, because this response is so confused that I think you're beyond help.
SHA-1 is used to validate long messages.
1. The sender, Alice, computes the (relatively short) SHA-1 hash H of a long message M
2. Alice cryptographically signs the hash H with a signature S
3. Bob can verify the whole message by verifying that the hash H is correctly signed, and then re-computing the SHA-1 of the entire message M, to verify that his computed hash matches Alice's hash H.
If Eve can compute a "SHA-1 collision," Eve can make a fake package X (like, say, malware instead of a real software package) that has the same hash H as the message M that Alice has signed. With that, Eve can trick Bob into accepting her malware by presenting Bob with her fake message X and Alice's real signature S. This works, because Alice really did sign hash H, and X and M have the same hash; their signatures have "collided" with catastrophic results.
To say that SHA-1 is "only broken for collisions" is to say that SHA-1 is broken for PGP.
Anyway, I'm done here. I hope we both agree that you deserve PGP.
You are describing a second preimage attack, ie, Eve finds a colliding message that matches an existing message and hash generated by Alice.
Not even MD5 is vulnerable to a second preimage attack.
The actual problem with SHA-1 is that Eve can generate two different messages with the same hash, one innocuous and one malicious. If Eve can get Alice to sign the innocuous message then Eve can use the signature to attack Bob using the malicious message.
Collisions are still catastrophic for most applications that use signatures, but it’s a wee bit harder to pull off an attack using pregenerated collisions than if you can find a second preimage. (Collision-based attacks need a signing oracle whereas second preimages do not.)
> I'll tell you what: instead of "don't use PGP," how about "Don't use SHA-1 and don't use any tool that accepts SHA-1 by default."
OK - lets see the implications of this:
> Today, in 2020, that means "don't use ...
Debian.
(As far as I can tell, the known SHA1 attacks have no practical impact on the security of using PGP to sign software updates, where the key management isn't reliant on web of trust... )
In practice, Debian downloads your packages over HTTPS from reliable trusted parties. HTTPS is the real, actual defense against package manipulation. The PGP signatures do nothing, but they don't really need to work; that's why nobody's bothered to fix them.
No, a default Debian installation downloads packages over plain HTTP. It doesn’t even support downloading packages over HTTPS unless you install the optional apt-transport-https package and edit your sources.list.
I was gonna say something about phone numbers and network analysis, but the link above said it better.
>>1 Mobile number
>>Unlike obsolete encryption systems, we require mobile phone to register in our system. Your account is tied to your phone number. Never mind that in many countries around the world SIM-cards can be bought only after presenting a legal ID, and that mobile networks themselves have all-encompassing LI (Lawful Interception) interfaces by design. Also let's ignore the fact that mobile networks still heavily rely on SS7 protocol stack from the 70s, with the security model based on gentlemen's agreement. Some people claim that words "mobile network" and "secure" can't be used in the same sentence, but our security experts think it's very safe. Do you guys not have phones?
It would be great if that were possible. Git commit signing is something that I would love to see be more commonplace, since it is a key part of a secured code supply chain. At my workplace I lead a project to make commit signing mandatory on our git repos, which I wrote about here: https://eos.arista.com/commit-signing-with-git-at-enterprise... .
One of the painful aspects of this was using the gpg tools. They are products of an earlier age and don't display helpful error messages, nor do they display easy to parse messages. I realize that Sequoia doesn't currently have a JSON API, but it looks like one is planned for the future, so that it two thumbs up from me.
This is pretty exciting. Hope this gives the OpenPGP ecosystem a long needed push and more attention!
"Sequoia was started 3.5 years ago by Justus Winter, Kai Michaelis and me, Neal Walfield. Prior to working on Sequoia, the three of us had worked together at g10code on GnuPG."