4 ms·

ssh covers ssh and now signing, eg for git commits. The vouching and web of trust stuff never worked for mist people.

lrvick 11mo ago
Abusing ssh for signing is a silly thing to do in most cases when modern PGP tooling covers this and so many other use cases with established standards. Also, again, use keyoxide which is a modern decentralized alternative to keybase. You can vouch for yourself to bootstrap trust.
- epistasis 11mo ago
  Why do you call it abuse?
  - lrvick 11mo ago
    OpenSSH keys were only meant for signing OpenSSH connection handshakes. They were meant for authentication, not signing long lived data. This is why PGP has distinct authentication and signing subkey types which can have different policies and permissions. Using ssh authentication keys to also sign software is a total hack, and worse, means you are now using a single key for multiple distinct use cases without a subkey system, CA, or rotation strategy, or the ability to revoke a key for one use case without compromising others or forcing a full keychan rotation. Telling people to use a single private keypair for many unrelated use cases has always been short-sighted cryptography advice and still is. I get that gpg UX is remarkably bad and makes everyone want to run screaming from PGP, but modern tooling exists now and for all the things the PGP spec got wrong, it got a lot more right. Watching new solutions get wrong the few things PGP got right as an answer to PGP is kind of infuriating.
    - justincormack 11mo ago
      All the docs encourage you to use a different ssh key for signing I think; certainly I do.
      - lrvick 11mo ago
        There are not many reasons for signing without a strategy for key discovery and verification so others can verify your signatures are really yours and not that of an imposter. SSH Authenticaton subkeys are widely shared publicly on every git host I am aware of. If you use a separate key for signing than you use for authentication, then you throw away the only established SSH key discovery method. Now you solved the overloaded key problem, while making key discovery worse. Everyone seems to be trying to re-solve problems with ssh keys that PGP actually solved reasonably well.
        epistasis 11mo ago
        I'm only familiar with GitHub, but signing keys are kept entirely separate from authentication keys, and must be uploaded separately. A GitHub user's signing keys are available at a different API endpoint: https://api.github.com/users/username/ssh_signing_keys https://api.github.com/users/username/ssh_signing_keys https://docs.github.com/en/rest/users/ssh-signing-keys?apiVersion=2022-11-28#list-ssh-signing-keys-for-a-user https://docs.github.com/en/rest/users/ssh-signing-keys?apiVe... as opposed to the auth public keys, which are at: https://github.com/username.keys https://github.com/username.keys
        tux1968 11mo ago
        Isn't this more of a theoretical problem, rather than a practical one? In what situations do you want people to discover your key? You create a key pair for Github, upload the public key, and you're done; you can securely communicate with Github. Nobody ever has to discover it. Do they?
        lrvick 11mo ago
        > In what situations do you want people to discover your key Just to name some of the most common use cases I have: 1. When people in my orgs want to encrypt sensitive information to me, e.g in encrypted password databases over git. 2. When prospective new clients or security researchers want to encrypt sensitive requests to me via email. Have some in my inbox right now from today. 3. When people want to verify that commits or code reviews I signed on security critical software were really signed by me, and not masquerade malicious code as mine in a rebase, etc. 4. When people want to verify that public reproducible builds of artifacts I maintained are built by multiple maintainers. These use cases all rely on a well published set of public keys shared with the public in ways with sufficient history and signatures so no one can impersonate me or other maintainers, or make it possible to easily trick people to encrypting data to keys that are not really ours. I sign 100% of my commits, and 100% of all artifacts I maintain etc. Anyone claiming to be me on anything important without signatures from my very well established and easy to verify public keys, are not me. A PGP key is the only standardized cryptographic passport for the internet and if you don't attach your work to an easily verifiable key you are one compromised account away from having your online identity used for supply chain attacks. All major linux distributions and the core infrastructure on the internet is anchored in the PGP keys of few thousand people that put in the work to maintain well published keychains. The only alternatives anyone have proposed are use Fulcio and let Google sign everything for you as a single point of failure for the internet. Hard pass. Meanwhile with solutions like keyoxide, anyone can form confidence my key is mine trivially without relying on a central party: https://keyoxide.org/6B61ECD76088748C70590D55E90A401336C8AAA9 https://keyoxide.org/6B61ECD76088748C70590D55E90A401336C8AAA...
    - somat 11mo ago
      So just out of curiosity, what is this modern tooling? It was brought up previously in this thread without naming any names.
      - lrvick 11mo ago
        Just to name a few of the projects I work on, use, or find most interesting: https://keyoxide.org/ https://keyoxide.org/ https://git.distrust.co/public/keyfork https://git.distrust.co/public/keyfork https://git.distrust.co/public/airgap https://git.distrust.co/public/airgap https://codeberg.org/heiko/openpgp-pkcs11 https://codeberg.org/heiko/openpgp-pkcs11 https://codeberg.org/openpgp-card/openpgp-card-tools https://codeberg.org/openpgp-card/openpgp-card-tools https://sequoia-pgp.org/ https://sequoia-pgp.org/ https://github.com/rpgp/rpgp https://github.com/rpgp/rpgp https://www.nitrokey.com/news/2021/new-nitrokey-3-nfc-usb-c-rust-common-criteria-eal-6 https://www.nitrokey.com/news/2021/new-nitrokey-3-nfc-usb-c-... https://doc.qubes-os.org/en/latest/user/security-in-qubes/split-gpg.html https://doc.qubes-os.org/en/latest/user/security-in-qubes/sp...
        tux1968 11mo ago
        It's hard to know how these pieces fit together, especially if you have a fuzzy mental-model of the objectives and potential benefits. Is there a gentle introduction you'd recommend?
        lrvick 11mo ago
        There are many ways to use PGP just as there are many ways to use openssl or any other cryptographic suite of tools. For most individuals seeking to establish a long term durable personal keychain they want others to be able to externally trust and verify easily, I would suggest the following, which is more or less what most people in my circles do: 1. Buy a smartcard with touch support such as a Nitrokey 3 2. Ideally buy 3+ backup smartcards at the same time 3. Use Keyfork on AirgapOS booted on a laptop you trust to generate a 24 word mnemonic and split-encrypt it to 3+ smartcards (or write down mnemonic on paper if you lack budget for 3 extra smartcards) 4. If using backup smartcard set, split them up across 3 secure locations, or if using a raw mnemonic put on durable storage such as cryptosteel, and put that in tamper evident storage such as in a vacuum sealed bag with confetti with pictures you have copies of elsewhere. 5. Use keyfork to derive a PGP key and load it into your smartcard 6. Setup forced/locked "touch" requirement policies on all "slots" on your card so you must tap for each use (malware cannot do this, but easy for you to do) 7. Publish public key to keys.ogenpgp.org 8. Publish public key on your own domain name using Web Key Discovery 9. Use keyoxide docs to establish keyoxide profile with every internet platform you control attesting your key fingerprint is yours to make it easy for others form confidence that all of those are you, and your key is yours. 10. Major bonus: use QubesOS and map your smartcard only to an offline vault VM that prompts you for each use, and which security domain on your system wants to use your key, so malware is unlikely to be able to trick you even if your development environment is compromised. From there you can use your provisioned smartcard with an openpgp smartcard capable ssh agent on your workstation for git signing, git push, ssh to servers, password management with password store, signing artifacts, thunderbird for email encryption, etc. We plan on writing up a lot more public documentation for this sort of thing as the public docs suck, but we have helped thousands of people with this sort of thing. Pop into #!:matrix.org or #keyfork:matrix.org if you want any help or advice for specific use cases. A partially complete set of docs for different threat models is in progress at https://trove.distrust.co https://trove.distrust.co
aborsy 11mo ago
It’s not because WoT necessarily doesn’t work, but people simply don’t need to verify digital signatures. Whatever needs to be done is done internally by apps. Dark web runs on PGP. People with no technical knowledge use it. Nobody has broken their communication. Not that this is a good use case, just saying bums can use PGP too! The biggest use case is currently software signing. Like you would verify a master key for a project under TOFU model, once through several channels. From there, verifying software signed by keys signed ultimately by that master key is done easily and securely.

lrvick 11mo ago

Abusing ssh for signing is a silly thing to do in most cases when modern PGP tooling covers this and so many other use cases with established standards. Also, again, use keyoxide which is a modern decentralized alternative to keybase. You can vouch for yourself to bootstrap trust.

epistasis 11mo ago
Why do you call it abuse?
- lrvick 11mo ago
  OpenSSH keys were only meant for signing OpenSSH connection handshakes. They were meant for authentication, not signing long lived data. This is why PGP has distinct authentication and signing subkey types which can have different policies and permissions. Using ssh authentication keys to also sign software is a total hack, and worse, means you are now using a single key for multiple distinct use cases without a subkey system, CA, or rotation strategy, or the ability to revoke a key for one use case without compromising others or forcing a full keychan rotation. Telling people to use a single private keypair for many unrelated use cases has always been short-sighted cryptography advice and still is. I get that gpg UX is remarkably bad and makes everyone want to run screaming from PGP, but modern tooling exists now and for all the things the PGP spec got wrong, it got a lot more right. Watching new solutions get wrong the few things PGP got right as an answer to PGP is kind of infuriating.
  - justincormack 11mo ago
    All the docs encourage you to use a different ssh key for signing I think; certainly I do.
    - lrvick 11mo ago
      There are not many reasons for signing without a strategy for key discovery and verification so others can verify your signatures are really yours and not that of an imposter. SSH Authenticaton subkeys are widely shared publicly on every git host I am aware of. If you use a separate key for signing than you use for authentication, then you throw away the only established SSH key discovery method. Now you solved the overloaded key problem, while making key discovery worse. Everyone seems to be trying to re-solve problems with ssh keys that PGP actually solved reasonably well.
      - epistasis 11mo ago
        I'm only familiar with GitHub, but signing keys are kept entirely separate from authentication keys, and must be uploaded separately. A GitHub user's signing keys are available at a different API endpoint: https://api.github.com/users/username/ssh_signing_keys https://api.github.com/users/username/ssh_signing_keys https://docs.github.com/en/rest/users/ssh-signing-keys?apiVersion=2022-11-28#list-ssh-signing-keys-for-a-user https://docs.github.com/en/rest/users/ssh-signing-keys?apiVe... as opposed to the auth public keys, which are at: https://github.com/username.keys https://github.com/username.keys
      - tux1968 11mo ago
        Isn't this more of a theoretical problem, rather than a practical one? In what situations do you want people to discover your key? You create a key pair for Github, upload the public key, and you're done; you can securely communicate with Github. Nobody ever has to discover it. Do they?
        lrvick 11mo ago
        > In what situations do you want people to discover your key Just to name some of the most common use cases I have: 1. When people in my orgs want to encrypt sensitive information to me, e.g in encrypted password databases over git. 2. When prospective new clients or security researchers want to encrypt sensitive requests to me via email. Have some in my inbox right now from today. 3. When people want to verify that commits or code reviews I signed on security critical software were really signed by me, and not masquerade malicious code as mine in a rebase, etc. 4. When people want to verify that public reproducible builds of artifacts I maintained are built by multiple maintainers. These use cases all rely on a well published set of public keys shared with the public in ways with sufficient history and signatures so no one can impersonate me or other maintainers, or make it possible to easily trick people to encrypting data to keys that are not really ours. I sign 100% of my commits, and 100% of all artifacts I maintain etc. Anyone claiming to be me on anything important without signatures from my very well established and easy to verify public keys, are not me. A PGP key is the only standardized cryptographic passport for the internet and if you don't attach your work to an easily verifiable key you are one compromised account away from having your online identity used for supply chain attacks. All major linux distributions and the core infrastructure on the internet is anchored in the PGP keys of few thousand people that put in the work to maintain well published keychains. The only alternatives anyone have proposed are use Fulcio and let Google sign everything for you as a single point of failure for the internet. Hard pass. Meanwhile with solutions like keyoxide, anyone can form confidence my key is mine trivially without relying on a central party: https://keyoxide.org/6B61ECD76088748C70590D55E90A401336C8AAA9 https://keyoxide.org/6B61ECD76088748C70590D55E90A401336C8AAA...
  - somat 11mo ago
    So just out of curiosity, what is this modern tooling? It was brought up previously in this thread without naming any names.
    - lrvick 11mo ago
      Just to name a few of the projects I work on, use, or find most interesting: https://keyoxide.org/ https://keyoxide.org/ https://git.distrust.co/public/keyfork https://git.distrust.co/public/keyfork https://git.distrust.co/public/airgap https://git.distrust.co/public/airgap https://codeberg.org/heiko/openpgp-pkcs11 https://codeberg.org/heiko/openpgp-pkcs11 https://codeberg.org/openpgp-card/openpgp-card-tools https://codeberg.org/openpgp-card/openpgp-card-tools https://sequoia-pgp.org/ https://sequoia-pgp.org/ https://github.com/rpgp/rpgp https://github.com/rpgp/rpgp https://www.nitrokey.com/news/2021/new-nitrokey-3-nfc-usb-c-rust-common-criteria-eal-6 https://www.nitrokey.com/news/2021/new-nitrokey-3-nfc-usb-c-... https://doc.qubes-os.org/en/latest/user/security-in-qubes/split-gpg.html https://doc.qubes-os.org/en/latest/user/security-in-qubes/sp...
      - tux1968 11mo ago
        It's hard to know how these pieces fit together, especially if you have a fuzzy mental-model of the objectives and potential benefits. Is there a gentle introduction you'd recommend?
        lrvick 11mo ago
        There are many ways to use PGP just as there are many ways to use openssl or any other cryptographic suite of tools. For most individuals seeking to establish a long term durable personal keychain they want others to be able to externally trust and verify easily, I would suggest the following, which is more or less what most people in my circles do: 1. Buy a smartcard with touch support such as a Nitrokey 3 2. Ideally buy 3+ backup smartcards at the same time 3. Use Keyfork on AirgapOS booted on a laptop you trust to generate a 24 word mnemonic and split-encrypt it to 3+ smartcards (or write down mnemonic on paper if you lack budget for 3 extra smartcards) 4. If using backup smartcard set, split them up across 3 secure locations, or if using a raw mnemonic put on durable storage such as cryptosteel, and put that in tamper evident storage such as in a vacuum sealed bag with confetti with pictures you have copies of elsewhere. 5. Use keyfork to derive a PGP key and load it into your smartcard 6. Setup forced/locked "touch" requirement policies on all "slots" on your card so you must tap for each use (malware cannot do this, but easy for you to do) 7. Publish public key to keys.ogenpgp.org 8. Publish public key on your own domain name using Web Key Discovery 9. Use keyoxide docs to establish keyoxide profile with every internet platform you control attesting your key fingerprint is yours to make it easy for others form confidence that all of those are you, and your key is yours. 10. Major bonus: use QubesOS and map your smartcard only to an offline vault VM that prompts you for each use, and which security domain on your system wants to use your key, so malware is unlikely to be able to trick you even if your development environment is compromised. From there you can use your provisioned smartcard with an openpgp smartcard capable ssh agent on your workstation for git signing, git push, ssh to servers, password management with password store, signing artifacts, thunderbird for email encryption, etc. We plan on writing up a lot more public documentation for this sort of thing as the public docs suck, but we have helped thousands of people with this sort of thing. Pop into #!:matrix.org or #keyfork:matrix.org if you want any help or advice for specific use cases. A partially complete set of docs for different threat models is in progress at https://trove.distrust.co https://trove.distrust.co

aborsy 11mo ago

It’s not because WoT necessarily doesn’t work, but people simply don’t need to verify digital signatures. Whatever needs to be done is done internally by apps. Dark web runs on PGP. People with no technical knowledge use it. Nobody has broken their communication. Not that this is a good use case, just saying bums can use PGP too! The biggest use case is currently software signing. Like you would verify a master key for a project under TOFU model, once through several channels. From there, verifying software signed by keys signed ultimately by that master key is done easily and securely.