A long time ago I was figuring out how to get public/private key encryption working on Windows with CryptAPI. I ultimately did, but I wasn't able to get all four crypto operations working. This is a short post to explain how a little epiphany blew my mind.
The four operations I had in mind were:
- Encrypt with private key
- Decrypt with private key
- Encrypt with public key
- Decrypt with public key
When I wrote my sample code to try all four of these combinations, I discovered that the last of these inexplicably didn't work. I chalked it up to to not finagling the right, arcane set of parameters to some CryptAPI functions, but I think it's more fundamental than that.
Actually, I think that even in theory, you only need only the first three for any security protocol. Let's look at the scenarios that these enable.
Alice wants to send to Bob securely. Alice has two options: encrypt with her private key, or encrypt with Bob's public key. Bob has two options: decrypt with her public key, or decrypt with his private key (respectively).
Likewise, if Bob wants to send back to Alice securely, we just reverse the roles. Bob can always encrypt with Alice's public key rather than force Alice to decrypt with his public key. TLS is architected this way, as can any protocol that relies on public/private key encryption.
This hit me like a Mack truck the other day so hard that I just had to write it down. Is your mind blown, too?
2 comments:
In our security class, we discussed Bob encrypting with his own private key so Alice could decrypt with Bob's public key. The idea was "signing" content - anything decrypted with Bob's public key would necessarily have to come from Bob, having been signed with his private key. This establishes a trusted source, right?
I dunno if that's a thing that's actually done in the real world, I'm not a security-minded guy, but I'm wondering if there is some arcanum still waiting for you in the CryptAPI.
You have a point, but in practice it seems TLS doesn't work that way. In TLS, if you want to mutually verify each other's identities, each party encrypts with the other's public key and decrypts with their own private key.
Your scheme would work if you encrypt with your own private key, then encrypt again with the recipient's public key.
I'd have to give it some more thought, but I'm not sure there's any real, added security from the way you mentioned. I think they can end up being basically equivalent, so maybe they arbitrarily picked one of the four not to use?
Post a Comment