5 ms·

Having an alternative implementation to GnuPG is a pretty important. Although many would argue against the use of PGP encryption for many use cases such as emai

by qqii 6y ago

Having an alternative implementation to GnuPG is a pretty important. Although many would argue against the use of PGP encryption for many use cases such as email, there are other use cases where PGP's ideas have no replacement. 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.

Leace 6y ago
> 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 https://keybase.io/blog/crypto) leaves the impression that they took PGP and embrace-extend-extinguished it...
- qqii 6y ago
  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.
  - Leace 6y ago
    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-repository-integrity-with-signed-commits https://mikegerwitz.com/2012/05/a-git-horror-story-repositor... [1]: https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation https://people.kernel.org/monsieuricon/introducing-b4-and-pa... By "keybase providing alternative" do you mean that they have hosted, encrypted git repos?
    - qqii 6y ago
      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?
      - Leace 6y ago
        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/ 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 https://github.com/wiktor-k/openpgp-proofs#openpgp-proofs
        qqii 6y ago
        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?
pot8n 6y ago
I am no cryptographer so take this with 2 bits of salt. AFAIK Keybase uses static-static DH for sending messages which actually can be worse than PGP since one peer's exposed private key automatically leads to compromise of all messages between the 2 peers, even if the other peer's private key is totally safe. So even if NaCl/libsodium AEAD is much more secure than PGP but when used in asynchronous messaging like in Keybase send messages can be more catastrophic when any of the peers has their key compromised.
forgotmypw16 6y ago
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.
- swiley 6y ago
  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.
  - DyslexicAtheist 6y ago
    > 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.
    - forgotmypw16 6y ago
      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.
  - GTP 6y ago
    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.
nickray 6y ago
First, that's a limitation of git. Second, it's easy to fake PGP: https://boats.gitlab.io/blog/post/signing-commits-without-gpg/ 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-612059329 https://github.com/solokeys/solo/issues/395#issuecomment-612... We're also collaborating with https://keys.pub/ https://keys.pub/ to make "sign/verify" use cases easily usable with a GUI for everyone. So I'd say there's hope?
- upofadown 6y ago
  >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.
- jeltz 6y ago
  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.
- qqii 6y ago
  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 https://news.ycombinator.com/item?id=22994650
lstoll 6y ago
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-verification https://github.blog/changelog/2018-09-10-smime-signature-ver...
- jcranmer 6y ago
  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.
- qqii 6y ago
  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 https://github.com/github/smimesign

by qqii 6y ago

Leace 6y ago

> 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 https://keybase.io/blog/crypto) leaves the impression that they took PGP and embrace-extend-extinguished it...

qqii 6y ago
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.
- Leace 6y ago
  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-repository-integrity-with-signed-commits https://mikegerwitz.com/2012/05/a-git-horror-story-repositor... [1]: https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation https://people.kernel.org/monsieuricon/introducing-b4-and-pa... By "keybase providing alternative" do you mean that they have hosted, encrypted git repos?
  - qqii 6y ago
    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?
    - Leace 6y ago
      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/ 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 https://github.com/wiktor-k/openpgp-proofs#openpgp-proofs
      - qqii 6y ago
        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?

pot8n 6y ago

I am no cryptographer so take this with 2 bits of salt. AFAIK Keybase uses static-static DH for sending messages which actually can be worse than PGP since one peer's exposed private key automatically leads to compromise of all messages between the 2 peers, even if the other peer's private key is totally safe. So even if NaCl/libsodium AEAD is much more secure than PGP but when used in asynchronous messaging like in Keybase send messages can be more catastrophic when any of the peers has their key compromised.

forgotmypw16 6y ago

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.

swiley 6y ago
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.
- DyslexicAtheist 6y ago
  > 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.
  - forgotmypw16 6y ago
    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.
- GTP 6y ago
  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.

nickray 6y ago

First, that's a limitation of git. Second, it's easy to fake PGP: https://boats.gitlab.io/blog/post/signing-commits-without-gpg/ 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-612059329 https://github.com/solokeys/solo/issues/395#issuecomment-612... We're also collaborating with https://keys.pub/ https://keys.pub/ to make "sign/verify" use cases easily usable with a GUI for everyone. So I'd say there's hope?

upofadown 6y ago
>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.
jeltz 6y ago
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.
qqii 6y ago
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 https://news.ycombinator.com/item?id=22994650

lstoll 6y ago

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-verification https://github.blog/changelog/2018-09-10-smime-signature-ver...

jcranmer 6y ago
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.
qqii 6y ago
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 https://github.com/github/smimesign