After researching and reading I am not sure if I completely understand it. To my knowledge, a key is a password used to decrypt a message. However, the confusion comes in when it comes to the public key, is the recipient putting in the password to receive the message?
-
2[This answer](http://security.stackexchange.com/questions/65622/client-server-encryption-technique-explanation-tls-ecdhe-rsa-with-aes-128-gcm-s/65645#65645) explains the different portions of cryptography, and might be helpful to you. – RoraΖ Jul 11 '16 at 16:35
-
[This video by Computerphile](https://www.youtube.com/watch?v=GSIDS_lvRv4) or [this one by Numberphile](https://www.youtube.com/watch?v=M7kEpw1tn50) are good introductions. – Jedi Jul 11 '16 at 17:33
-
The [Wikipedia](https://en.wikipedia.org/wiki/Key_(cryptography)#Key_vs_Password) has a section explaining the difference between keys and passwords. – Neil Smithline Jul 12 '16 at 02:12
4 Answers
Passwords are concerned with system access. They are used to verify that you are who you say you are (example: logging into email), or at least that you are someone that is allowed to access the resource you are trying to access (example: a code to open a door).
The important thing about passwords is that they are fed into a system, so extra measures like lockout (too many wrong attempts) or 2-factor verification (texting a code to your phone) can be implemented.
Keys, in the context of cryptography, are not passwords, they are used to change a message (plaintext) into an unreadable form (ciphertext). Think about it like this: you have an encryption machine. You feed your plaintext and your key into the machine and get scrambled letters and numbers out (the ciphertext). You secretly share your key with your friend, then you can send him your ciphertext, and it doesn't matter who sees it. Since your friend had the key, he gets your ciphertext and feeds it into his decryption machine along with his copy of your key, and the machine prints the original ciphertext.
This is a little more difficult to secure: there is a principal in cryptography that says you must assume that an enemy has intercepted the ciphertext and has a copy of the encryption and decryption machines. So he can try as many times as he's like to guess the key and there's nothing you can do to stop him.
The above describes a symmetric cryptosystem, where you kept the encryption key secret because the same key is used to both encrypt and decrypt the message (like locking a deadbolt on a door). This is different form asymmetric cryptosystems, in which the encryption key (the key used to lock the door) is different from the decryption key (the key used to unlock the door). This has the advantage that 2 parties don't need to secretly share the key before communicating. For example, I post to an online forum
"Bill, what's your address? - Please encrypt the answer using the encryption key 103234".
Now, Bill can encode his answer and post it for all to see, but because only the encryption key has been shared and I kept the private key to myself, so only I can decrypt it (not even Bill can decrypt it, even though he already knows the plaintext). Furthermore, now anyone can send me messages that only I can decrypt.
Note on terminology: an encryption-only key is usually called a "public key" since everyone can see it; a decryption-only key is usually called a "private key" since you don't share it with anyone.
Technical note: while asymmetric cryptography seems superior, it is a LOT more computationally intensive (bad for, say, encrypting terabytes of info) compared to symmetric cryptography
- 31
- 1
I am not sure I can answer this question perfectly, but I'll try.
First off, think of symmetric algorithms.
One such algorithm is a method to encipher(encrypt) a message, and must be completed with a key, in order to tell the algorithm exactly how to encipher said message.
The enciphered message is called cipher-text.
The recipient of the cipher-text must also feed the same key to the decryption algorithm in order to recover the original message from the cipher-text. If you don't have that key, you can't read the content.
Public key cryptography can be a bit confusing, and even classic cryptography experts used to think it was impossible to do.
Public key (asymmetric) algorithms are similar to private key(symmetric) algorithms in that they both require a key for encryption and decryption, however with the first one, sender and recipient use the same key, and must keep it a secret, but with the second, two different keys are used for these two operations, one public, which the recipient wants everybody to have, that is used for encryption, and a second, private, that is used for decryption and must be kept secret by the recipient.
To go back to your literal key analogy, you may think of symmetric algorithms as vaults, that can only be accessed by people who own a key, and of asymmetric algorithms as mail boxes where anybody can insert anything, through the slot(public key), but can only be opened by the box owner who has the mail box key(private key).
-
I had a task today that involved a PKI and was able to understand it better. I had the user encrypt his outgoing messages in Outlook 2013. Only the recipient who has the private key that matches the public key used to encrypt the message can decipher the message for reading; also for additional security I suggested the user, uses a digital signature to sign the message. The main thing that's confusing to me is how is it formed if it's separate from a password. More like the science behind it, but that will come a long to me with more experience and studying, thanks. – Kev Jul 13 '16 at 00:54
Early forms of cryptography were based on secret encryption algorithms, but it soon became apparent that this was a terribly bad idea. If you suspect the algorithm is learned by the enemy then they can potentially decode everything and you have to throw it all away and start again. And algorithms are hard to think up.
A better idea is to use a key. In a key based system, the algorithm is not secret, instead the secrecy is all condensed into a large random number called the key. The encryption algorithm takes the plaintext message and combines it with the key using some long series of mathematical processes to produce the encrypted message. In order to reverse the algorithm the recipient must also have the key.
Now the algorithm is not secret, so experts can examine it to confirm it is secure, and if the key is compromised, you just throw it away and pick a long new random number. Heck, use a new key every time you send a message, then even if a key is compromised without you knowing the enemy can only read one message.
That's keys. You also talk about passwords, which are different, and public keys, which are a special kind of key. Both are used to solve some irritating practical problems with using keys as part of a system for exchanging messages.
The first practical problem with keys is that since a key is just a big random number, humans find it very difficult to memorise them. If your system needs a person to remember the key and not write it down, then you have a problem. A password is a combination of letters and characters that a human can remember. Your system can use something called a key derivation algorithm that takes a password and turns it into a key. Password based systems are not as good as systems that just use a key, but it's a limitation of human beings, not much we can do.
So you don't really use a password to decode a message, you use it to generate the key and then use the key to decode the message.
The other practical problem with keys is called key distribution. Before I can securely send you a message we have to both know the key, so I have to give it to you. But I can't send it to you encrypted, because you don't have the key yet. And I can;t send it plain text, because what if a bad guy is listening in?
In many systems there is a way to exchange keys over a separate secure channel. For example, M can give Bond the key he should use before he sets out on his mission, while they're still safely in MI6 headquarters.
But sometimes this is not possible, especially over the internet, where we usually only have the internet to communicate over. So a new trick is required, public key cryptography.
In this type of system, I have two keys that are mathematically related. If a message is encrypted by one of the keys, it can only be decrypted by the other one. I call one the private key, and keep it secret; I call the other the public key, and tell everyone what it is.
Now you can send me a secure message by encrypting it with the public key. An attacker can listen in as much as they like, I've already told them the public key, but that's no good to them, only the person with the other, private key (me) can decrypt the message you sent.
For boring practical reasons, you typically only use public/private key once in a conversation, right at the start so you can safely exchange keys over an untrusted line, and then use a regular single key encryption method for the actual message. So you don't really use a public or private key to decode a message, you use it to safely swap a third key, and then you use that to decode the message.
- 15,474
- 37
- 63
-
Jumping into the comments to point out that of course Bond knows his OpSec and so uses codes,not ciphers. Or lets the local station do the encryption for him. – Graham Hill Jul 11 '16 at 18:08
To my knowledge, a key is a password used to decrypt a message.
The Key is built out of a Password Derivation function. The function (i.e. PBKDF2, or a repetetive SHA-256) is designed to take a notable amount of load. (i.e. 250ms)
The derived Key is more difficult to guess than the original password (i.e. defend against a rented cluster trying to brute-force your key)
The derived Key will more easily match the desired key size for your every-day block-cipher encryption.
However, the confusion comes in when it comes to the public key, is the recipient putting in the password to receive the message?
I had the exact question myself. It seems impossible to get a secure, public-use system, without the receiver getting the secret key ahead of time.
Symmetric Encryption is simpler. The same key is used for decryption and encryption.
Asymmetric, or Public-Key cryptography has one key that can only be used for Encryption, and the other for Decryption.
If you pass these keys in the right order, and combine that with a Certificate, then you can log on to your Online Banking account and your connection is secured against eavesdropping or impersonation.
(and, without the need for prior key exchange)
A common implementation of this is RSA, uses the 'power-of' operator.
If you take a cheap calculator with Square and Square-Root buttons, and select 'Squared' (power of 2) on a complex number, then the result will be instant, as it is simple multiplication. However, 'square-root' on a complex (very long) enough number will have a small noticeable delay. This is because it is mathematically much more difficult to reverse.'
In RSA, we use power of X, where X is a huge (secret) number, so that reversing it would be quite expensive indeed. That becomes the key.
See: Is it possible to have a key for encryption, that cannot be used for decryption?
Working example: Is there a simple example of an Asymmetric encryption/decryption routine?
- 13,897
- 3
- 53
- 82