Fwd: public/private keys.... what are they?

[Joseph Sinclair]

Lots of confusion here.  Let me try to clarify (a small amount).

Background:
"Public Key" cryptography is also called "Asymmetric Cryptography".
The reason is that there are two different keys, and they only work together in an "asymmetric" fashion (whatever one key does, the other key undoes).
The keys are "related" mathematically, but it is (currently) not possible to figure out one key from the other (so having a public key does not help you determine the private key).

1) There are two keys.
  a) There are also two *actions*, encryption (hiding content from unauthorized viewers) and verification (proving a message is authentic and from a known entity).
2) *Either* key can be used to encrypt, but the *other* key is needed to decrypt.
  a) that means public(encrypt) ==> private(decrypt) *or* private(encrypt) ==> public(decrypt).
  b) a single key cannot both encrypt and decrypt the same message (That's why it's called "asymmetric encryption", the keys are *not* interchangeable).
3) The "Public" key  is meant to be published far and wide.  It is used to encrypt a message intended for the key "owner", and it is also used (by decrypting a hash) to "verify" that a message was sent by the real owner (signature).
4) The "Private" key is meant to be kept strictly secret.  It can decrypt any message encrypted by the public key.  It can also encrypt a message that only the "Public" key can decrypt (see signature below).

Encryption is the function most people understand (it's also very rarely used**).  You encrypt a message using the "Public" key as the encryption key.
Once encrypted the data is essentially static to anyone who does not possess the "Private" key.
There are a ton of details involved, so it's rarely explained further than that without reading an entire textbook (or 3).

There is a *related* function called "verification" or "Digital Signature".  This is used to prove (without ever exposing a secret) that a particular entity possesses the secret "Private" key.
This is how you know your HTTPS connection is connected to the correct endpoint rather than some imposter (it's also how ssh passwordless login works).
This involves (very simplified) using the "Private" key to encrypt the hash of a message (to sign the message) or a "nonce" value (to verify endpoint identity, e.g. SSL).
Once the value (hash or nonce) is encrypted by the "Private" key, only the matching "Public" key will decrypt it.
So if someone sent you a message and it's encrypted hash, then you decrypt the hash with the "Public" key, and if it decrypts correctly you know it is valid.
Of course, you would also hash the message (there are standard algorithms for generating these "hash" values) and see if your results match what you decrypted (if they don't, then the message isn't what the sender meant to send).

There are several ways of implementing assymetric cryptography, the most commonly used is with the RSA family of algorithms.
The "elliptic curve" (or "EC") family of algorithms have grown in popularity in recent years, but are still only occasionally used.
The two are mostly different in the mathematics behind how and why they work.
The basic concepts (two keys, two operations, what one key does the other undoes) are the same.

Hopefully that helps a bit.

Public Key Cryptography (and Asymmetric Cryptography in general) is a huge and complex topic, so I second Todd's suggestion that if you want to really understand this, you will want to read a few good textbooks on the subject.

==Joseph++

** Some will say that SSL uses public key encryption.  This is true, but misleading, because the public key encryption is only used during the "handshake" where the SSL connection is setup to encrypt the exchange of symmetric keys.  This "key exchange" is what Diffie and Helman invented that makes modern PKI possible.
The encryption that does all the heavy lifting of keeping the SSL tunnel secure is always a "block" (symmetric) algorithm, most commonly AES (for modern systems where security is properly implemented) or 3DES (slightly older but still pretty secure) or RC4 (completely insecure and used by extremely badly managed sites running ancient and horribly flawed web server software, unfortunately there are still far too many very large businesses that do this).


On 02/09/2015 06:01 PM, Michael Havens wrote:
> helps some but you state:
> 
> you want others to be able to check that you actually
> sent the message (by using your public key)
> 
> Where do they get your public key?
> How does your public key and private key decrypt when it seems the public
> key changes.
> 
> :-)~MIKE~(-:
> 
> On Mon, Feb 9, 2015 at 5:48 PM, someone wrote:
> 
>> So if I'm right calling it a 'key' is a misnomer. I am a very literal
>> person. if they call it a key it unlocks things, not creates them.
>> That is where my confusion is from. Am I correct?
>>
>> Not quite correct...
>>
>> Both the public and private keys ARE keys... they're just used a
>> little differently.
>>
>> You keep your private key secure, and use it to digitally sign a
>> message when you want others to be able to check that you actually
>> sent the message (by using your public key). Others can send an
>> encrypted message that only you can decode, by encrypting the message
>> using your public key. When you get the message, you can use your
>> private key to undo the encryption that was done using your public
>> key.
>>
>> So, in a way, the public and private keys can be thought of as two
>> pieces of a single, combined key. The software that does the signing
>> or encryption (using the keys), such as gnupg, pgp, etc., is more like
>> the lock that the keys fit.
>>
>> I hope that helps.
>> --
>> Kevin O'Connor
>>
> 
> 
> 
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20150209/4454a895/attachment.pgp>