this post was submitted on 11 Apr 2025
217 points (95.8% liked)

Programmer Humor

22354 readers
2832 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 4 points 3 days ago* (last edited 3 days ago) (1 children)

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.

[–] [email protected] 2 points 3 days ago (1 children)

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.

[–] [email protected] 4 points 3 days ago (2 children)

Signing isn't encryption. It's a non-cipher hash.

$ ❯ 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;

-----BEGIN SSH SIGNATURE-----
U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgCwxAYX85ptsTc+Dtz3a0IRondh
qFF3wKMsTqt+c4oGMAAAAEZmlsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQyNTUx
OQAAAECvqKLkm+kWUgFh0bI8jYIR5BPUaq76MZ94exp2yUn+KnK5YA79ggFY/C4VsnDqJp
SAedWp4eOUwPNG8RR59KsP
-----END SSH SIGNATURE-----

And can then be verified using my public key;

❯ 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
[–] [email protected] 2 points 3 days ago (1 children)

Mathematically, signing is encryption using the private key. That's how the algorithm works. The input to the function is irrelevant.

[–] [email protected] 0 points 3 days ago* (last edited 2 days ago) (1 children)

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

[–] [email protected] 3 points 2 days ago

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.

[–] [email protected] 1 points 3 days ago

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.