To ensure global uniqueness of namespaces, SSH recommends that you That the signature is considered valid by the second protocol even though it was meant If the protocols don't use distinct namespaces for their signatures, there's a risk This prevents cross-protocol attacks whereby a valid signature is removed fromĪ message for one protocol and attached to a message from a different protocol. If you are using the signature for a different purpose, such as aĬustom protocol, you must specify your own namespace. Signing generic files, and email for signing emails. If you have an RSA key, use id_rsaįile is the "namespace", which describes the ~/.ssh/id_ed25519 is the path to your private key. Here are the arguments you may need to change: Ssh-keygen -Y sign -f ~/.ssh/id_ed25519 -n file file_to_sign Sign Git tags since my PGP keys expired in 2018.īut that will soon change in Git 2.34, which adds support Have to use either PGP or S/MIME, and personally I haven't bothered to That your code hasn't been tampered with. Signing Git commits and tags gives consumers of your repository assurance You'll soon be able to sign Git commits and tags with SSH Makes SSH signatures a good alternative to S/MIME as well! SSH has a lightweight certificate system that is considerably simpler Shouldn't) but if certificates would make your life easier, You don't have to use SSH certificates (and most people SSH has optional lightweight certificates. Key Transparency would address the concerns with trusted third parties, ifĪnyone ever figures out how to audit transparency logs in practice.) Like GitHub seems like a way better default than PGP's Web of Trust, People's public keys, so it may not be appropriate for all use cases.īut relying on a trusted third party with a professional security team (GitHub acts as a trusted third party here, and you have to trust them not to lie about SSH public keys for any GitHub user by visiting a URL like GitHub already acts as a key distribution service which isįar easier to use and more secure than any of the PGP key servers ever were. You don't need to use the Web of Trust or worry about configuring "trust levels"įor keys. SSH public keys are one line strings that are easy to copy around. Signify and minisign are great, but require you to install new softwareĪnd generate new keys, which will hinder widespread adoption. Why I'm more excited about SSH signatures than other PGP signature alternatives Or newer, you already have a new enough version of SSH installed.Īnd if you use GitHub, or any other service that uses SSH keys forĪuthentication, you already have an SSH key that can be used to If you use Debian Bullseye or Ubuntu 20.04 SSH is everywhere, and people already have SSH keys. PGP is absurdly complex, has an awful user experience,Īnd is full of crufty old cryptography which shouldn't be touched with The alarm on PGP, including its most popular implementation, For years, security professionals have been sounding Should consider switching to SSH signatures. If you're currently using PGP to sign data, you It's super useful and the most viable alternative OpenSSH 8.0 - it seems to be little-known. Did you know that you can use the ssh-keygen command to sign and verify signatures onĪrbitrary data, like files and software releases? Although this feature isn't super new - it was added in 2019 with
0 Comments
Leave a Reply. |