2d ago

me when i find out i can use ssh to sign my git commits

34 comments

The only real advantage to using SSH vs PGP keys is you don't need an external dependency (GPG). PGP is always going to be better, because you get the advantage of WOT, and PGP public key servers to verify identities over just "this is who I am, here's my key." You should always sign your commits, no matter what you use. Identity verification is very important in open source.
cli

$ git config --global gpg.format ssh $ git config --global user.signingkey ~/.ssh/examplekey.pub
- Are you using your public ssh key for signing? Wouldn't it make more sense to use the private one as people can then verify your identity by using your public key?
  
  Ha, good catch! Behind the scences, git is actually using your private key to sign the commit. You're only specifying the ssh key git should ask ssh-agent about. You can also specify the private key and actually need to when not using an agent and the key is not available. See docs
  
  OH! Now I see! Thanks for pointing that out.
  
  You seem to be fundamentally misunderstanding how the shared keys work, here. You don't get to choose which key you sign with, either private or public.
  If you sign a statement, it uses your private key. Period. The methodology is only the original owner of the keys has access to the private key, so any signed statement also using that private key, is directly from the key owner. Alternatively, anyone has access to your private key, and can encrypt data using it, that only the owner, with access to the private key, can decrypt.
  Anyone in the world can encrypt a message that only you can decrypt. That's the way it works. Alternatively, when you sign a statement, you're establishing that the owner of the key pair signed it, as only the owner has access to the private key. Then, anyone in the world can verify your signed statement using your public key.
  You don't get to choose which one you use. In the example from my original post, the ssh-agent only needs reference to the location of one of the two keys, and will use the filename regardless, to distinguish between public and private. If I point the configuration option to this_is_my_key indicating a private key, it will automatically use this_is_my_key.pub as a public key. If I indicate this_is_my_key.pub then it does the reverse and will assume that this_is_my_key is the private key. It doesn't matter which one you specify, the ssh-agent just needs a filename to work with.
  
  second paragraph should have "anyone has access to your public key"
  
  Anyone only has access to your public key if you give them access to your public key. So no, not really. They should have access to it. It's not something you should keep private, but SSH shared keys aren't PGP shared keys. There's no key servers for SSH shared keys.
  
  look at last sentence of the second paragraph. Is this what you wanted to write?
  
  Then, anyone in the world can verify your signed statement using your public key.
  Of course. The only barrier is the possession of your public key. I really don't understand what you're getting at here. Anyone with your public key can verify a PSK signed statement you made, which obviously is predicated on them having access to the key.
  
  that's 3rd
  
  "Alternatively, anyone has access to your ~~private~~ public key, and can encrypt data using it, that only the owner, with access to the private key, can decrypt."
  
  Public is used to encrypt, private is used to decrypt.
  
  But why? Public is public. People can take my public key. The can encrypt my commit, making it indistinguishable from my commit.
  Isn't the idea to use your private key for encryption so that everyone can use your public key to decrypt your signature and to verify that it's you who actually did the commit, because no one else has access to the private key?
  
  Consider a key pair, consisting of two brutally large numbers, but otherwise pretty much identical. Magical math exists that makes it so that if you math your data with one of these brutally large numbers, you get the original data back only if you math it with the other large number. That's basically it.
  Now we slap convention onto this, and keep one of the paired, large numbers a secret, and call it our private key, the other number is disseminated and called the public key for that reason.
  Now everyone can math data with your public key, so that only the paired private key, which only you know, can de-math it. This is encryption/decryption.
  Signing is very similar, but now you use your private key, which only you know, to math a digest of your data, and all the world can de-math this correctly only with your public key, thus proving it was indeed your private key used to math the data in the first place, and by extension attribute the signature to your public key identity. Your private key is never known to anyone but you, which is an essential difference to "classical" symmetric encryption with a shared secret.
  You may realize how easily a code signature can become a liability, if you fail to keep your private key secret for any reason. You can be trivially impersonated, with basically no chance of recourse or deniability with an SSH key, while you can at least invalidate a GPG key publicly and mark it as "stolen" that way. This is potentially very important, if there's any legal meaning attached to your signature, and if not, why bother with code signing in the first place, if "trust me bro" is well enough.
  
  Yeah, sorry, I meant signing, not encrypting. I know about asymmetrical encryption. That's why I was confused by the original statement. For signing you use your private key so that others can verify your identity by using your public key for checking the signature. For encrypting data you use the public key of the receiver.
  ~~The original comment used the public key for signing, which is not what you want to do.~~ I now read the explanation.
  
  Did you reply to the correct comment?
  
  People can take my public key.
  And they can also encrypt things with it. That's the whole point. Only the owner of the private key can decrypt what's been encrypted with the public key, and that establishes ownership.
  Why the person you responded to is being down-voted, and why people in this thread don't seem to understand how shared keys work is pretty insane to me. This technology has exited, and remained relatively unchanged, for like... 40 years.
  The can encrypt my commit, making it indistinguishable from my commit.
  That's not how commits are verified. The commit is signed with your private key (not encrypted), not your public key. Referencing the public key simply tells the ssh agent which key-pair to use, and the ssh daemon decides which key to use (public or private) based on the action that you're doing.
  Signing a commit requires your private key, so no. People can't just grab your public key and sign commits to impersonate you. They can simply encrypt text with it. That's it. This is all self evident by the git property user.signingkey "sign". You're signing the commit message, not encrypting anything.
  
  Sorry for the confusion about "encryption". I meant "signing" which is encrypting a hash of the commit with your private key, so that others can verify that your the author of the commit using your public key and the hash.
  I think, the only confusion here was the original comment that referenced the public key for signing, but this was resolved, as it is just telling git which key pair to use. Probably, all people here understand the basics of asymmetrical encryption and signing and it was merely misunderstanding of how the command for signing git commits can be used.
  
  Signing isn't encryption. It's a non-cipher hash.
  cli
  
  $ ❯ echo "This is a signed message." | ssh-keygen -Y sign -n file -f ~/.ssh/id_ed25519 > content.txt.sig Signing data on standard input
  Which outputs the hash of the signed statement, which was signed with my private key;
  ssh
  
  -----BEGIN SSH SIGNATURE----- U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgCwxAYX85ptsTc+Dtz3a0IRondh qFF3wKMsTqt+c4oGMAAAAEZmlsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQyNTUx OQAAAECvqKLkm+kWUgFh0bI8jYIR5BPUaq76MZ94exp2yUn+KnK5YA79ggFY/C4VsnDqJp SAedWp4eOUwPNG8RR59KsP -----END SSH SIGNATURE-----
  And can then be verified using my public key;
  cli
  
  ❯ echo "This is a signed message." | ssh-keygen -Y check-novalidate -n file -f ~/.ssh/id_ed25519.pub -s content.txt.sig Good "file" signature with ED25519 key SHA256:ltAIkPgF9rLt1KlRRh6tQUtWNT8/wErhtAibmSHfbVs
  
  Mathematically, signing is encryption using the private key. That's how the algorithm works. The input to the function is irrelevant.
  
  Mathematically, they're not even close to the same. How you could ever assert such an indefensibly and empirically incorrect statement is beyond my reasoning skills to understand.
  PKC Key signing uses hashing algorithms like RSA, ElGamal, DSA, and ECDSA to create one way cryptographic hashes for given input data. The singular purpose of these signatures is to verify the integrity of data. Not to protect the data in any way whatsoever or to be reversed into clear text; again, the hash is one way.
  PKC encryption uses encryption algorithms like AES, Blowfish, Twofish, PGP, and Diffie-Hellman to create reversible cipher text. The difference being, the cipher text of an encryption process can be reversed and represents the data itself.
  All of this is clearly outlined in the RFC: https://www.ietf.org/rfc/rfc4880.txt
  
  I know it because I've actually implemented RSA as an exercise and know how it works.
  What you're talking about with hashes is an implementation detail. It's an important one, because using exactly the same algorithm for signing and encryption has some security pitfalls, and it will usually be slower. However, the function you call is exactly the same. The hash is encrypted with the private key. It can be verified by generating the same hash, decrypting with the public key, and matching the two hashes.
  See also: https://cryptobook.nakov.com/digital-signatures/rsa-signatures
  Signing a message msg with the private key exponent d:
  Calculate the message hash: h = hash(msg)
  Encrypt h to calculate the signature: s = h^d (mod n)
  The operation "h^d (mod n)" is just RSA encryption, but with the private key.
  
  Thanks for that rabbit hole. My former colleagues and I have just started a new conversation thread in our WhatsApp group about the differences of (non-) cryptographic hashes and encryption. And all because I was confused why you've chosen to reference the public key file in your original comment. Well, at least I'm learning something.
  
  I think encrypting with a public key is mostly used in client -> server traffic (client encrypts with server's public key, server decrypts with private), and not code signing. However, I'm no TLS/asymmetric crypto savant.
  
  Encryption can only be done with the PGP public key. Even if you specifically use the private key, it contains the public key, and GPG already knows to use the public key for encryption. You cannot create encrypted cipher text using a GPG private key.
  Likewise, you cannot decrypt data using the public key, nor can you sign statements with a public key. For those processes you must use a private key.
  I had no idea people found GPG this confusing...
  
  I don't have much experience in the realm of gpg. My experience is mostly with TLS. From what I know, if you're doing client authentication, you encrypt your message with your private key, and then the public key on a cert is used for validating that the message actually came from you.
  I think code signing is similar to client auth, but not positive. Again, I use TLS, but I'm not a professional
  https://about.signpath.io/code-signing/theory#%3A%7E%3Atext=Software+publishers+use+a+secret%2Cpart+of+the+distribution+package.
  Edit:
  What I found from Wikipedia:
  The client sends a CertificateVerify message, which is a signature over the previous handshake messages using the client's certificate's private key. This signature can be verified by using the client's certificate's public key. This lets the server know that the client has access to the private key of the certificate and thus owns the certificate.
  https://en.m.wikipedia.org/wiki/Transport_Layer_Security#Client-authenticated_TLS_handshake
  
  This is TLS authentication via SSH, which is a completely different ballgame than using SSH keys for data encryption, decryption, and verification.
- Wouldn't that mean you'd have to share your public key anyway?
  I have the same repos in multiple vms, keeping tabs of that key would be... interesting, considering i often use passwordless-logins across the board.
  
  Wouldn’t that mean you’d have to share your public key anyway?
  Public keys aren't meant to be private. The function is literally in the name... But no, you don't necessarily have to share your public key, but for someone to verify that a specific public key was used to sign a commit, the public key is required. So there's absolutely no reason to sign your commits if you intend on keeping your public key, private... It completely defeats the entire purpose....
  
  Thanks, i know what "public" means.
  I don't see "not usually installed on your system" as a strong enough disadvantage to PGP for this use case.

34 comments