Towards Sequoia OpenPGP v1.0(sequoia-pgp.org)
sequoia-pgp.org
Towards Sequoia OpenPGP v1.0
https://sequoia-pgp.org/blog/2020/04/26/202004-towards-sequoia-v1.0/
61 comments
> Personally keybase is the only project that may provide some form of alternative, but they do so by supporting pgp.
Why keybase? Reading their crypto page (https://keybase.io/blog/crypto) leaves the impression that they took PGP and embrace-extend-extinguished it...
Why keybase? Reading their crypto page (https://keybase.io/blog/crypto) leaves the impression that they took PGP and embrace-extend-extinguished it...
I'm not endorsing keybase, in fact I have much of the same criticisms as you probably do.
The fact is unlike many PGP replacements most don't attempt to solve similar ideas as the "web of trust". For those that I know do, the cryptocurrency/tokens one's don't even consider backwards compatability. As far as I know keybase are the only ones that embrace PGP and are therefore backwards compatible with git, fossil, etc's commit signing.
It may be ignorance but I don't see linux, git or any other software project that "needs" both version control and verifiable commits moving from PGP signing to something else, but rather PGP signing dying out with the rise of git platforms like github, gitlab, etc. If you squint you can see that keybase provides some form of alternative.
The fact is unlike many PGP replacements most don't attempt to solve similar ideas as the "web of trust". For those that I know do, the cryptocurrency/tokens one's don't even consider backwards compatability. As far as I know keybase are the only ones that embrace PGP and are therefore backwards compatible with git, fossil, etc's commit signing.
It may be ignorance but I don't see linux, git or any other software project that "needs" both version control and verifiable commits moving from PGP signing to something else, but rather PGP signing dying out with the rise of git platforms like github, gitlab, etc. If you squint you can see that keybase provides some form of alternative.
To be honest even PGP signing has some issues: it's not clear what does it mean to sign a commit and there is plenty of misuse of that (see [0], `git push --signed` solves some of these issues).
Git patch workflow doesn't support signed commits and some kernel devs explore alternative ways of signing [1].
[0]: https://mikegerwitz.com/2012/05/a-git-horror-story-repositor...
[1]: https://people.kernel.org/monsieuricon/introducing-b4-and-pa...
By "keybase providing alternative" do you mean that they have hosted, encrypted git repos?
Git patch workflow doesn't support signed commits and some kernel devs explore alternative ways of signing [1].
[0]: https://mikegerwitz.com/2012/05/a-git-horror-story-repositor...
[1]: https://people.kernel.org/monsieuricon/introducing-b4-and-pa...
By "keybase providing alternative" do you mean that they have hosted, encrypted git repos?
I now see how my original wording is confusing. I'm using git not as the specific case here (albeit interesting) but as an example. From my understanding keybase attempts to solve some of the more questions in your first link, simply 'r/commit/post/g'. For example:
> He certainly knows his own posts, but how should others know that this “Linus Torvalds” guy who has been posting and commenting on posts is actually Linus Torvalds?
Perhaps that makes my other comments more clear?
> He certainly knows his own posts, but how should others know that this “Linus Torvalds” guy who has been posting and commenting on posts is actually Linus Torvalds?
Perhaps that makes my other comments more clear?
Yeah... I guess a little bit it does. Keybase offers an alternative to Web of Trust that kernel.org itself uses (https://www.kernel.org/doc/wot/). Keybase solution is having multiple social-proofs instead of the Web of Trust. Sadly this is unnecessarily centralized but I've seen approaches to implement Keybase-like social proofs systems in pure OpenPGP: https://github.com/wiktor-k/openpgp-proofs#openpgp-proofs
Ooh, I've not seen wiktor-k/openpgp-proofs before. Too bad it doesn't have more adoption, as I like it's solution to keybase's centralization.
Sadly neither project has an elegant solution to private accounts or services. IRC usernames and Signal are examples of the second. For private accounts, both solutions need specific tool integration, cooperation between services, or more manual interaction by the user. Ideally, a new internet standard would be created and adopted, but I really don't see that happening.
As someone who's put thought into this, I'm wondering what your thoughts on this are?
Sadly neither project has an elegant solution to private accounts or services. IRC usernames and Signal are examples of the second. For private accounts, both solutions need specific tool integration, cooperation between services, or more manual interaction by the user. Ideally, a new internet standard would be created and adopted, but I really don't see that happening.
As someone who's put thought into this, I'm wondering what your thoughts on this are?
I'm using OpenPGP.js for drop-in decentralized client-side authentication for my web-based message board.
This has several benefits, which includes giving technically-savvy users to do their own key generation and message signing using whatever tools they prefer, using one of the most widely used encryption/signing standards in existence.
Meanwhile, non-technical users can create a new profile with literally one click and a couple seconds of compute time on their device. They can then back up the key as a text-file and use it on any compatible site.
I think that the potential of PGP has barely been grazed by Keybase, and there are many more applications than we've even hypothesized so far.
This has several benefits, which includes giving technically-savvy users to do their own key generation and message signing using whatever tools they prefer, using one of the most widely used encryption/signing standards in existence.
Meanwhile, non-technical users can create a new profile with literally one click and a couple seconds of compute time on their device. They can then back up the key as a text-file and use it on any compatible site.
I think that the potential of PGP has barely been grazed by Keybase, and there are many more applications than we've even hypothesized so far.
You should definitely not be encouraging your users to give their private keys to js on other sites, that’s just as bad (or maybe worse) as encouraging them to reuse passwords.
That's a good point... Perhaps a better solution is for them to be able to sign the public keys from the other sites to connect their profiles that way.
Thank you for your feedback. I can see now how a malicious system operator could steal the user's private key by modifying the JS.
Thank you for your feedback. I can see now how a malicious system operator could steal the user's private key by modifying the JS.
He's talking about giving their public key, not the private key that has to remain on the user's device(s) under all circumstances.
The private key is stored in localStorage, but this is not the user's "real" private key which they might use for email, but a temporary device key, which can then be vouched either by admin or by user.
I'm not understanding how this works, then. Are you using the user's private key to somehow derive temporary device keys?
Generate a PGP key using in-browser JS. Use that key submitted posts.
Then, later, sign either the file hashes or the public key itself using actual secure PGP. This is optional.
I'm not claiming any level of security, this is all mostly UI prototyping.
Then, later, sign either the file hashes or the public key itself using actual secure PGP. This is optional.
I'm not claiming any level of security, this is all mostly UI prototyping.
Sorry, what do you mean by "Use that key submitted posts"?
> encouraging your users to give their private keys
I read it twice and still can't find the place where it was mentioned this to be the case.
I read it twice and still can't find the place where it was mentioned this to be the case.
I'm generating the keys in-browser for device-specific keys. I am not asking the users to provide their existing private keys, but I am storing the device keys in localStorage, because, where else?
The advanced users can then use their existing PGP keys to sign the device keys.
But this is not necessary in every environment, because in some situations, e.g. casual chat or internal boards, you don't need that kind of extended security, and temporary device keys, perhaps vouched by the operator, are sufficient.
The advanced users can then use their existing PGP keys to sign the device keys.
But this is not necessary in every environment, because in some situations, e.g. casual chat or internal boards, you don't need that kind of extended security, and temporary device keys, perhaps vouched by the operator, are sufficient.
That sounds really interesting, would you be willing to share a link to the message board so I can see what your account creation process looks like? The other most common place I've seen PGP used as an account identifier are in darknet markets, where users are warned to use a GPG binary from a trusted source and against whatever serverside system that was built for ease of UX.
Related to the issue that swiley mentions, I'm not really sold that attributing the user to a string of digits is good UX, whereas I like how keybase puts a distinction between identity and secrets.
A "keybase proof" simply shows that at some point a singular identity had access to a multitude of accounts, but has no guarantees about the current account holders. This may seem like a negative but shifting the responsibility onto account holders to protect their secrets is more reasonable than assigning the identity of an individual to a single, long term secret [0] or deal with key transition.
[0]: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html#...
Related to the issue that swiley mentions, I'm not really sold that attributing the user to a string of digits is good UX, whereas I like how keybase puts a distinction between identity and secrets.
A "keybase proof" simply shows that at some point a singular identity had access to a multitude of accounts, but has no guarantees about the current account holders. This may seem like a negative but shifting the responsibility onto account holders to protect their secrets is more reasonable than assigning the identity of an individual to a single, long term secret [0] or deal with key transition.
[0]: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html#...
http://hike.qdb.us/profile.html
js required for key generation
js required for key generation
First, that's a limitation of git.
Second, it's easy to fake PGP: https://boats.gitlab.io/blog/post/signing-commits-without-gp...
Third, we're adding support to SoloKeys to do this using a hardware token: https://github.com/solokeys/solo/issues/395#issuecomment-612...
We're also collaborating with https://keys.pub/ to make "sign/verify" use cases easily usable with a GUI for everyone. So I'd say there's hope?
Second, it's easy to fake PGP: https://boats.gitlab.io/blog/post/signing-commits-without-gp...
Third, we're adding support to SoloKeys to do this using a hardware token: https://github.com/solokeys/solo/issues/395#issuecomment-612...
We're also collaborating with https://keys.pub/ to make "sign/verify" use cases easily usable with a GUI for everyone. So I'd say there's hope?
Your linked post is not about faking PGP, it is about replacing PGP with his own implementation which supports only a subset of the PGP standard, the subset necessary to properly sign git commits.
I've not made myself very clear in the comment, but git and fossil scm are simply examples that delegate issues of trust to PGP's web of trust. Hardware keys are more secure, but from my understanding still stuffer from the same issue PGP does - a physical device is not an identity. keys.pub looks very interesting, but it seems that like keybase it doesn't address everyone's concerns[0].
From a technical perspective if keys.pub exists there's no reason that the proof process could occur at a layer above git rather than within git in some form of "social proof sidechain"-like structure.
I'm definitely going to keep an eye on key.pub, once they've addressed some of their coming soon items they'll be a very nice contender to keybase.
[0]: https://news.ycombinator.com/item?id=22994650
From a technical perspective if keys.pub exists there's no reason that the proof process could occur at a layer above git rather than within git in some form of "social proof sidechain"-like structure.
I'm definitely going to keep an eye on key.pub, once they've addressed some of their coming soon items they'll be a very nice contender to keybase.
[0]: https://news.ycombinator.com/item?id=22994650
>Second, it's easy to fake PGP:
An odd way to put it, but yes, the simplicity of the OpenPGP standard is one of its greatest strengths. Somehow the standard has resisted just a ton of stuff that would be pointless over the long term over a great many years.
An odd way to put it, but yes, the simplicity of the OpenPGP standard is one of its greatest strengths. Somehow the standard has resisted just a ton of stuff that would be pointless over the long term over a great many years.
Git also supports S/MIME, and GitHub provides a tool to sign commits with this directly https://github.blog/changelog/2018-09-10-smime-signature-ver...
S/MIME and PGP share the same basic problem: they provide a container for the basic public-key crypto primitives (signing and encryption) together with an identification of the public key and leave it at that. Throw on top of that tools that are usually uninterested in actually thinking about how policy decisions affect cryptographic security and you have an example of security theater.
I've seen similar projects that use S/MIME for identity management, but as seen from the README of the tool[0] the benefits of PGP's web of trust can be seen in unstructured environments. Online identities are perhaps the most unstructured environment, where aliases and personas are the norm.
[0]: https://github.com/github/smimesign
[0]: https://github.com/github/smimesign
As someone who has been trying to use this library but haven't had the time to finish build integration to cross compile for all of my target platforms, I really wish it weren't using nettle, particularly as it is also using openssl :(. Does rust not have useful cryptography libraries yet? Or couldn't it just openssl?
I still use PGP to encrypt files with secrets in them that I am sending to a known source, and I know it's still the base encryption for a few well known file servers. A new player in the market is welcomed.
[deleted]
Keybase's "Crypto tools" tab can do this, with "known destination" determined via social proof.
https://keys.pub is a re-implementation of this use case without the messenger/cryptocurrency baggage that some dislike about Keybase.
https://keys.pub is a re-implementation of this use case without the messenger/cryptocurrency baggage that some dislike about Keybase.
Here's the command line documentation:
https://docs.sequoia-pgp.org/sq/index.html
I have to admit that it looks more digestible than gpg's. It seems it's still missing a way to manage OpenPGP smartcards like Yubikeys. Also, I can't see a way to manage an arbitrary set of subkeys for a given primary key.
I'm really happy to see an alternative to GnuPG, though. This looks promising.
https://docs.sequoia-pgp.org/sq/index.html
I have to admit that it looks more digestible than gpg's. It seems it's still missing a way to manage OpenPGP smartcards like Yubikeys. Also, I can't see a way to manage an arbitrary set of subkeys for a given primary key.
I'm really happy to see an alternative to GnuPG, though. This looks promising.
Off topic af: what does the picture on their landing page symbolize? https://sequoia-pgp.org/
Note that this project is unrelated to Sequoia Capital.
I guess it's a reference to Sequoyah https://en.wikipedia.org/wiki/Sequoyah
note that Sequoia Capital is totally unrelated to the Indian silversmith and inventor of the Cherokee syllabary
What's the threat model?
I've looked into the code. It uses Nettle's Curve25519 which seems to be implemented constant-time (assuming ECC mul is using "ecc-mul-g" from which is protected against cache timing attacks because the other ecc-mul implementations are using raw table access.)
I've looked into the code. It uses Nettle's Curve25519 which seems to be implemented constant-time (assuming ECC mul is using "ecc-mul-g" from which is protected against cache timing attacks because the other ecc-mul implementations are using raw table access.)
IMO, encrypted e-mail is a dead end. Latacora has a good blog post about it that I highly recommend: https://latacora.micro.blog/2020/02/19/stop-using-encrypted....
Whenever someone criticizes email encryption they fail to provide an actual replacement. Encrypted instant messaging is an alternative, but it's not a replacement.
That post should really be called, "Stop using email". Which is fine when you don't need something like email. But sometimes you do.
Although I agree with your point, both the article and your comment suffer from different use cases + threat models.
I'd agree that there are no real alternatives to (regular) mail and email where longer form asynchronous communication can occur without the expectation of an instant reply.
Unfortunately when it comes to this form of communication the reality is that there aren't any widely used alternatives that don't leak as much metadata as email.
I'd agree that there are no real alternatives to (regular) mail and email where longer form asynchronous communication can occur without the expectation of an instant reply.
Unfortunately when it comes to this form of communication the reality is that there aren't any widely used alternatives that don't leak as much metadata as email.
Hmm, I don't really see any really convincing points, or workable alternatives that your linked article provides.
Nevertheless I would like to read more about this claim:
> It [PGP] was designed in the 1990s, and in the 20 years since it became popular, cryptography has advanced in ways that PGP has not kept up with. So, for example, it recently turned out to be possible for eavesdroppers to decrypt messages without a key, simply by tampering with encrypted messages. Most technologists who work with PGP don’t understand it at a low enough level to see what’s wrong with it.
(I admit I am one of these technologists)
Nevertheless I would like to read more about this claim:
> It [PGP] was designed in the 1990s, and in the 20 years since it became popular, cryptography has advanced in ways that PGP has not kept up with. So, for example, it recently turned out to be possible for eavesdroppers to decrypt messages without a key, simply by tampering with encrypted messages. Most technologists who work with PGP don’t understand it at a low enough level to see what’s wrong with it.
(I admit I am one of these technologists)
My best guess is that they really meant EFAIL but didn't want to actually mention it because EFAIL had nothing to do with any weakness in the OpenPGP standard or the GnuPG implementation. Instead it was a HTML email horror story where someone figured out how to forward entire decrypted messages using image links.
So just more pointless anti-PGP innuendo...
So just more pointless anti-PGP innuendo...
That is not in fact a good description of EFail, which was indeed caused by a failure both of the PGP protocol and of GPG, its reference implementation.
>...a failure both of the PGP protocol ...
No. There were some changes in the actual protocol document that came out of EFAIL but no actual changes to the protocol other than a depreciation that was happening anyway.
>...and of GPG, ...
This also seems to be false. GPG didn't have to change anything as the result of EFAIL...
>...its reference implementation.
Also false. OpenPGP does not have a reference implementation.
No. There were some changes in the actual protocol document that came out of EFAIL but no actual changes to the protocol other than a depreciation that was happening anyway.
>...and of GPG, ...
This also seems to be false. GPG didn't have to change anything as the result of EFAIL...
>...its reference implementation.
Also false. OpenPGP does not have a reference implementation.
There were no changes in TLS after Bleichenbacher '98; instead, implementations just incorporated increasingly hacky workarounds. The PGP post upthread details the problems with the MDC, and the compounding implementation flaw in GPG that released unauthenticated plaintext to callers.
That MDC-era PGP remains the global standard, and that GPG continues to release unauthenticated plaintext to callers, just calls out further the impossibly compromised position PGP-based cryptosystems are in. You can try to do things like Sequoia that modernize PGP, but nobody in the installed base will be compatible with you, and the most popular and important "driver" of the protocol (again, GPG) is disinterested in mitigating the flaws of legacy PGP.
You can choose not to call GPG the PGP reference implementation, and there's no formal declaration anywhere saying that, but, it obviously is.
That MDC-era PGP remains the global standard, and that GPG continues to release unauthenticated plaintext to callers, just calls out further the impossibly compromised position PGP-based cryptosystems are in. You can try to do things like Sequoia that modernize PGP, but nobody in the installed base will be compatible with you, and the most popular and important "driver" of the protocol (again, GPG) is disinterested in mitigating the flaws of legacy PGP.
You can choose not to call GPG the PGP reference implementation, and there's no formal declaration anywhere saying that, but, it obviously is.
It is odd you bring up MDC in the context of EFAIL as the EFAIL researchers were unable to come up with an exploit that MDC did not detect. Even if you feel that GPG should of anticipated EFAIL that means that OpenPGP as a protocol was secure against EFAIL.
It is entirely accurate to say that EFAIL in not applicable to OpenPGP. You might not like MDC but you have to admit that EFAIL is not an example of any sort of a weakness in MDC.
It is entirely accurate to say that EFAIL in not applicable to OpenPGP. You might not like MDC but you have to admit that EFAIL is not an example of any sort of a weakness in MDC.
I feel like we're not reading the same paper. The EFail paper I'm reading has a prominent chart showing which implementations it was possible to break the MDC in, and a section detailing how the MDC can be straightforwardly stripped off messages.
I note that you didn't respond to the rest of my comment.
I note that you didn't respond to the rest of my comment.
Yeah, the paper did not claim that the MDC was in any sense "stripped off messages". They instead claimed that the mail clients ignored the MDC error.
>I note that you didn't respond to the rest of my comment.
The TLS stuff? We are just quibbling here. You have an irrational hate of things called PGP. Nothing I can say is going to change that.
Added: You are the one that brought up the MDC stuff but that really is beside the point. The problem here is with the leakage that HTML emails allow. EFAIL would still have nothing to do with PGP even if MDC did not exist.
>I note that you didn't respond to the rest of my comment.
The TLS stuff? We are just quibbling here. You have an irrational hate of things called PGP. Nothing I can say is going to change that.
Added: You are the one that brought up the MDC stuff but that really is beside the point. The problem here is with the leakage that HTML emails allow. EFAIL would still have nothing to do with PGP even if MDC did not exist.
Search the Enigmail forums for people who couldn't open their emails after GnuPG made MDCs mandatory (as a reaction of Efail). Especially people with old PGP keys were receiving non-MDC (SE) ciphertexts since ever. Mozilla's bugzilla (and a bank I heart of) were using non-MDC encryption. Reading the OpenPGP RFC, this is perfectly fine behaviour.
The Efail paper also describes a way to downgrade MDC ciphertexts to SE ciphertexts. This was known since 2015, but not addressed in OpenPGP.
So OpenPGP according to RFC 4880 allows SE packets with no MDC, and the MDC can be stripped away in a standard conforming way (tho with some guessing of bytes). If that isn't a problem with the OpenPGP standard, I don't know what is.
Just weeks after Efail, they made SE packets (those with no MDC) deprecated in the current RFC 4880bis. They were careful to not mention Efail, because it wasn't OpenPGP's fault. For some, it's never OpenPGP's fault.
The Efail paper also describes a way to downgrade MDC ciphertexts to SE ciphertexts. This was known since 2015, but not addressed in OpenPGP.
So OpenPGP according to RFC 4880 allows SE packets with no MDC, and the MDC can be stripped away in a standard conforming way (tho with some guessing of bytes). If that isn't a problem with the OpenPGP standard, I don't know what is.
Just weeks after Efail, they made SE packets (those with no MDC) deprecated in the current RFC 4880bis. They were careful to not mention Efail, because it wasn't OpenPGP's fault. For some, it's never OpenPGP's fault.
Interesting. I was not aware of this particular issue. Is this it?
* https://dev.gnupg.org/T3981
As mentioned in the discussion:
>Actually this is not related to the mentioned CVE because the issue we are talking about has not been tested by them.
So it appears that the EFAIL people could of prevented MDC from thwarting their attack if they had used a really old cypher. So, OK I will concede that EFAIL at least inspired a change in GPG. My original statement that GPG required no changes as a result of EFAIL is still correct as stated though.
We are still quibbling here. I don't think that S/MIME was deficient in any way with respect to EFAIL either. So all this discussion about MDC is still pointless to me.
* https://dev.gnupg.org/T3981
As mentioned in the discussion:
>Actually this is not related to the mentioned CVE because the issue we are talking about has not been tested by them.
So it appears that the EFAIL people could of prevented MDC from thwarting their attack if they had used a really old cypher. So, OK I will concede that EFAIL at least inspired a change in GPG. My original statement that GPG required no changes as a result of EFAIL is still correct as stated though.
We are still quibbling here. I don't think that S/MIME was deficient in any way with respect to EFAIL either. So all this discussion about MDC is still pointless to me.
It is talking about things like efail.
I wrote an actual piece about PGP:
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
I stand by what I wrote in this post as well, but it's not a good first read for people surprised that cryptographers hate PGP.
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
I stand by what I wrote in this post as well, but it's not a good first read for people surprised that cryptographers hate PGP.
Perhaps I should have linked to both essays. People should read them both :) The reason I linked to the other one was that encrypted mails is the first use case listed on the Sequoia site.
PGP is used for more than just email
The writer of the article wrote another one that is linked where he criticises other uses of PGP[0].
[0]: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
[0]: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
Some of those issues are just properties of GPG and could be fixed by an alternative implementation, while others look inherent to the standard.
Agreed, can be used for signing git and other stuff. PGP isn't only about encryption, it's also about authentication and integrity.
For a specific example take signing git commits. Even fossil scm delegates this task to pgp. Personally keybase is the only project that may provide some form of alternative, but they do so by supporting pgp.
I definitely agree that PGP was and is no longer the correct tool for every use case as it sort out to be, but I find there are still pockets where PGP has no alternative. I'd be interested what HN's thoughts are on PGP for this specific use case and if there could be an alternative.