Public Key, Private Key, Secret Key: Everyday Encryption

Wednesday, June 30, 2010

Rod MacPherson

314f19f082e69886c20e31c70fe6dceb

I recently wrote the CISA exam. That's #2 of my "big infosec certifications" (CISSP last year being the first) One thing I found in the exam prep classes for both certifications was that many people have trouble with the concepts behind the modern day encryptions that we all use every day.

I was browsing through other blog posts today and came across it again. Even in the infosec industry, some folks still just don't get every day encryption. 

There are 2 basic types of encryption that we use every single day of our lives. Everyone uses them. Even my Grandma. 

Type 1 is Symmetric, aka Single Key, aka Secret key, aka super-fast... Note how all the S words go together :)

Type 2 is Asymmetric, aka Public Key/Private Key (or just public key for short), aka Two Key, aka really-fricking-slow encryption. This is what people generally THINK they are using when they use PGP. (they are, but they are also using Symmetric encryption to do the bulk of the work)

When you use Asymmetric (public key) encryption to send an e-mail to someone you don't encrypt the whole message using public and private keys. That would be painfully slow and a waste of CPU time. Here is what really happens:

Bob wants to send a message to Sue. 

Bob writes his message, addresses it to Sue and hits the encrypt button on his e-mail client. 

Bob's email client (which already has Sue's public key that they exchanged off-line somehow at some time prior to this e-mail) runs the whole message through some hashing algorithm like MD5 or one of the SHA hashes. This gives a short hash that is representative of the whole message, but only 128-512 bits (depending on which hashing algorithm his software uses) 128 bits is small enough to not take long to encrypt with public key encryption, so it then takes that hash and encrypts it with Bob's private key (which only Bob has) thus creating a message digest that proves not only that the message didn't change (else the hash would be different) but also that it was Bob who sent it (else this hash will not decrypt when Sue tries to verify it later).

Bob's software then takes the whole message and encrypts it  with a fast Symmetric (single key) encryption cipher. If Bob's message was long it would be slow to encrypt the whole thing with his Private key or Sue's Public key. Asymmetric encryption just takes too much calculation to do on a large scale.

Now Bob's software has an encrypted message (done with a Symmetric cipher, a shared key for that cipher and an asymmetricly encrypted message digest. We need to get the Symmetric key to Sue so that only she can use it to open the message, so we encrypt that key (only the key, not the whole message) with Sue's Public Key. Since the Symmetric key is also only about 128 bits long it is quick to encrypt with the Asymmetric cipher. 

Now we have a Symmetricly encrypted message, an Asymmetricly encrypted message digest done with Bob's Private key, and an Asymmetricly encrypted shared key done with Sue's Public key. 

Only Sue, with her Private key, can unwrap that shared key to unwrap the whole message.  With Bob's Public key she can unwrap the hash from the message digest to prove Bob did send the message, and she can run the same hashing algorithm on the message and compare the hash she calculates to the hash Bob sent to verify that the message didn't change in transit. 

If Bob wanted to CC: others on that message, his software would only have to wrap the little 128 bit key again with their Public key so that they too would be able to decrypt the message. This should only increase the total e-mail size by about 128 bits, not doubling it. :)

His program should do this with his own public key so that, when he goes to read his sent mail that he encrypted to Sue, he can.

This same process applies to PGP, S/MIME, SSL, SSH, SFTP.... we all use this process every day of our internet using lives, but it happens invisibly behind the scenes, so very few people seem to really understand the steps.

Editors Note: For clarity and accuracy, the author requested the the following changes be made to the original text: All occurances of "Synchronous" were replaced with "Symmetric" and "Asynchronous" with "Asymmetric" - 12/17/10.

Possibly Related Articles:
21817
Security Training
Encryption
Post Rating I Like this!
1812c2be1b7978f540f3a758646b3f44
Marc Massar Usually people refer to the two types of encryption as symmetric and asymmetric. Synchronous and asynchronous often imply an aspect of time that is not present in the encryption schemes you are discussing.
1277928543
314f19f082e69886c20e31c70fe6dceb
Rod MacPherson Right you are Marc. Sorry about any confusion I caused anyone. That's what happens when I rush to get a blog post out during lunch.

Maybe I should have saved this and proof read it before submitting.
1277937972
Default-avatar
Slim Amamou People are confused because the wording is confusing. Security is about people, identities and trust. It's not about keys and doors.

Maybe it's too late now, but we should say Identity instead of Key.
1277939415
Default-avatar
Patrick Sweeney @Slim

I agree completely that PKI, and its requisite use of keys can be confusing. However, I disagree completely on the idea of using the term "identity" instead.

In the big pciture, security is indeed about people, identities and trust, but PKI (Public Key Architecture) is about... keys.

I think far too many InfoSec folks mistake having control of a key as _being_ someone. This leads to the absurd notion that using a key establishes identity. It _suggests_ an identity, but that's really as far as it can go.

The _keys_ in a given PKI exchange are indeed irrefutably identified. The individuals using the keys, however, may or may not be the actual owners of the respective keys. We simply can't know. That's a very real, and all-too-often overlooked, distinction.

As a rough analogy... Some other guy could find a way to use my phone, and then call a friend of mine. Caller-id on my friend's phone will say it's me, but that doesn't make it true.

My vote is to leave the word "identity" for actual identities, and "key" for... well, keys.

- Patrick
1277943152
Default-avatar
Slim Amamou I'm not mistaking having control of a key as being someone. In fact we can share the same identity indeed. If we share the same phone number for example. But the other way around is more common : people have multiple identities on the internet, that's the culture of the internet.

People have multiple identities in blogs, social networks, email addresses. And those are infrastructure for trust through history. Which is one way to have trust.

The other way to have trust is delegation of authority (that's what PKI is) and again, it seems to me, identity is the central artifact.

In my view, the concept of Identity is emerging from the culture of the internet. And a better model for the overall trust architecture would be 1 Identity != 1 Person but 1 Identity = 1 Key.
1277948832
Daf33b816cab0eff806965a308f32db6
Dan Heitzmann @Rod, Great article!

@Slim, I'm not sure that I'm following your point. I get what you say about multiple identities...but while we may have multiple logon ID's and passwords, I'm not sure how common it is to have multiple Key's...
1277991280
Default-avatar
Rob Lewis @Patrick,

Good that you remember the human element. Security is about end behavors.

The language of the business rules is indeed that of user trust relationships within and between user groups, and the corresponding privileges that govern end behaviors.

Things get even more complicated when persons are assigned multiple roles for provisioning and least privilege purposes and one could face the prospect of juggling multiple identities and keys.

However, crypto/PKI is one tool and hardly a panacea at that. For all its progress, it does not deal with the big problem from the human perspective, and that is protecting data in use.
1277996751
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.