❯ 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, 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.
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.
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.
Signing isn’t encryption. It’s a non-cipher hash.
Which outputs the hash of the signed statement, which was signed with my private key;
And can then be verified using my public key;
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
The operation “hd (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.