4 ms·

Keyfork only uses modern ECC PGP keys supported by the spec, prioritizing smartcard use, and using BIP32 KDF from a 256 bit mnemonic seed. Nothing else comes c

by lrvick 1y ago

Keyfork only uses modern ECC PGP keys supported by the spec, prioritizing smartcard use, and using BIP32 KDF from a 256 bit mnemonic seed. Nothing else comes close to the broad compatibility PGP offers. Just need to ignore legacy ciphers. I suggest looking at the links. Latacoras take on this is IMO wildly out of date (6 years old to be fair). PGP powers the core software supply chain security trust layer for the Linux distributions and tooling that power the whole internet and the standard does get updated. PGP is not going away, but it is being upgraded.

tptacek 1y ago
The post covers this (not Keyfork itself, but Sequoia, on which Keyfork appears to depend).
- lrvick 1y ago
  Sequoia is only used as a library for a few crypto primitives that there are multiple alternatives for now we will be switching to. Thankully, because of standards, we can switch to a leaner library set without breaking compatibility. https://codeberg.org/heiko/pkcs11-openpgp-notes https://codeberg.org/heiko/pkcs11-openpgp-notes
  - tptacek 1y ago
    I think you should read the post. It's mostly not about things implementations can improve about the PGP ecosystem on their own. Then, I think you should talk to professional cryptography engineers. I'd be interested if you could find even one who believes the PGP ecosystem should be kept going. My distaste for PGP is not an idiosyncrasy; it's something I learned from cryptographers, who fucking hate PGP.
    - lrvick 1y ago
      I read it when it was first posted and my team and I have personally done a lot to address some of the more fair points like UX. Keyfork makes the UX story dead simple for key generation and backup. Keyoxide makes key discovery and trust bootstrapping dramatically easier as well. As far as those with cryptography engineering experience that see it as useful... I mean I have designed the backend key management systems and hardware security modules for several large financial institutions and hundreds of billions of dollars of infrastructure, and have worked closely with many cryptographers who review our work, and the supply chain security engineers responsible for signing commits, packages, and reproducible builds for major linux distributions including the one I founded. All of the above relies on PGP smartcards for signed commits, commit pushes, ssh, signed reviews, trust bootstrapping, because no other tooling or spec has that covered with multiple competing implementations to choose from as well as PGP. The only fair point in the article still relevant today IMO is forward secrecy but any tooling that really needs that like an instant messenger would use ciphers and protocals designed for that. PGP would just be used as an identity CA to bootstrap trust in those cases if anything.
      - tptacek 1y ago
        I've done similar work and would not describe myself as a cryptography engineer, just a systems person with a security specialization. (I've been pretty consistent about this point on HN, this isn't just something I'm saying because it's convenient for the thread). When you worked with those cryptographers, did any of them stick up for PGP? Which ones? I'm not making up the attitude I'm describing. How do you respond to the PGP format points raised in that post? How do you respond to the prevalence of the MDC construction?
        lrvick 1y ago
        > When you worked with those cryptographers, did any of them stick up for PGP? Which ones? I'm not making up the attitude I'm describing. I am not going to drag anyone else or their reputations into this conversation but they can chime in if they want to. The general vibe I get about PGP among the cryptography engineers in my universe, that I share, is that it is an awkward spec that would have never been designed today, and has a lot of legacy ciphers that should never be used anymore that modern tooling must not expose, etc. But also, that re-inventing very widely used and established standards and tools that are secure enough for those use cases is rarely worth it. PGP is the bootstrap trust layer for the internet, governments, linux distros, and critical infrastructure all over the world and it is not going away, so might as well take advantage of the compatibility wins of modernizing it. We would have designed HTTP and TLS and the internet as a whole a -lot- differently today too. They are broken as hell but the job is to improve and upgrade even when it would be more fun to start over. In hindsight, everything is shit. But I am not about to try to make a new internet and convince people to use it. That is more complex to do than living with and working around the early dumb design choices when they can be made secure. We do not just abandon HTTP and TLS, we navigate early awkward choices and we debate and iterate on new versions of standards. Similarly, many teams including mine, put in the work to modernize PGP tooling, and the OpenPGP working group still exists and still iterates on the standard (Though admittedly not as much as many of us would like). As for MDC, another thing that is awkward, but good enough: https://articles.59.ca/doku.php?id=pgpfan:mdc https://articles.59.ca/doku.php?id=pgpfan:mdc It is my general opinion that for all the faults of PGP, it is still the best personal cryptographic identity anchored encryption and signing solution we have, especially when combined with smartcards and keyoxide. From there a rich ecosystem of tooling builds on top of that. PGP (with modern tooling and ciphers) is much more sensible to recommend overa fragmented set of one trick tools with no key discovery, validation, or backup strategy that are bound to leave users with lost, stolen, or impersonated keys.

by lrvick 1y ago

tptacek 1y ago

The post covers this (not Keyfork itself, but Sequoia, on which Keyfork appears to depend).

lrvick 1y ago
Sequoia is only used as a library for a few crypto primitives that there are multiple alternatives for now we will be switching to. Thankully, because of standards, we can switch to a leaner library set without breaking compatibility. https://codeberg.org/heiko/pkcs11-openpgp-notes https://codeberg.org/heiko/pkcs11-openpgp-notes
- tptacek 1y ago
  I think you should read the post. It's mostly not about things implementations can improve about the PGP ecosystem on their own. Then, I think you should talk to professional cryptography engineers. I'd be interested if you could find even one who believes the PGP ecosystem should be kept going. My distaste for PGP is not an idiosyncrasy; it's something I learned from cryptographers, who fucking hate PGP.
  - lrvick 1y ago
    I read it when it was first posted and my team and I have personally done a lot to address some of the more fair points like UX. Keyfork makes the UX story dead simple for key generation and backup. Keyoxide makes key discovery and trust bootstrapping dramatically easier as well. As far as those with cryptography engineering experience that see it as useful... I mean I have designed the backend key management systems and hardware security modules for several large financial institutions and hundreds of billions of dollars of infrastructure, and have worked closely with many cryptographers who review our work, and the supply chain security engineers responsible for signing commits, packages, and reproducible builds for major linux distributions including the one I founded. All of the above relies on PGP smartcards for signed commits, commit pushes, ssh, signed reviews, trust bootstrapping, because no other tooling or spec has that covered with multiple competing implementations to choose from as well as PGP. The only fair point in the article still relevant today IMO is forward secrecy but any tooling that really needs that like an instant messenger would use ciphers and protocals designed for that. PGP would just be used as an identity CA to bootstrap trust in those cases if anything.
    - tptacek 1y ago
      I've done similar work and would not describe myself as a cryptography engineer, just a systems person with a security specialization. (I've been pretty consistent about this point on HN, this isn't just something I'm saying because it's convenient for the thread). When you worked with those cryptographers, did any of them stick up for PGP? Which ones? I'm not making up the attitude I'm describing. How do you respond to the PGP format points raised in that post? How do you respond to the prevalence of the MDC construction?
      - lrvick 1y ago
        > When you worked with those cryptographers, did any of them stick up for PGP? Which ones? I'm not making up the attitude I'm describing. I am not going to drag anyone else or their reputations into this conversation but they can chime in if they want to. The general vibe I get about PGP among the cryptography engineers in my universe, that I share, is that it is an awkward spec that would have never been designed today, and has a lot of legacy ciphers that should never be used anymore that modern tooling must not expose, etc. But also, that re-inventing very widely used and established standards and tools that are secure enough for those use cases is rarely worth it. PGP is the bootstrap trust layer for the internet, governments, linux distros, and critical infrastructure all over the world and it is not going away, so might as well take advantage of the compatibility wins of modernizing it. We would have designed HTTP and TLS and the internet as a whole a -lot- differently today too. They are broken as hell but the job is to improve and upgrade even when it would be more fun to start over. In hindsight, everything is shit. But I am not about to try to make a new internet and convince people to use it. That is more complex to do than living with and working around the early dumb design choices when they can be made secure. We do not just abandon HTTP and TLS, we navigate early awkward choices and we debate and iterate on new versions of standards. Similarly, many teams including mine, put in the work to modernize PGP tooling, and the OpenPGP working group still exists and still iterates on the standard (Though admittedly not as much as many of us would like). As for MDC, another thing that is awkward, but good enough: https://articles.59.ca/doku.php?id=pgpfan:mdc https://articles.59.ca/doku.php?id=pgpfan:mdc It is my general opinion that for all the faults of PGP, it is still the best personal cryptographic identity anchored encryption and signing solution we have, especially when combined with smartcards and keyoxide. From there a rich ecosystem of tooling builds on top of that. PGP (with modern tooling and ciphers) is much more sensible to recommend overa fragmented set of one trick tools with no key discovery, validation, or backup strategy that are bound to leave users with lost, stolen, or impersonated keys.