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

Mon Feb 16 20:23:05 MST 2015

The method can very a bit.  Usually it goes like this.

Public key is shared with everyone.

Private key is only on the server.

Client generates a symmetric key, encypts it with the public key, and sends
it.  All the actual data you care about is encrypted with the symmetric key.

Server receives the symmetric key that has been encrypted with the public
key and decrypts it with the private key (usually the public and private
key combined, but that's beside the point).  Then decrypts the data with
the symmetric key it just got.

In this way, the very expensive asymmetric encryption system is used as
little as possible.  All your datas are encrypted with a much quicker
encryption method.  The symmetric key is discarded at the end of the
session.

On Mon, Feb 16, 2015 at 7:56 PM, Michael Havens <bmike1 at gmail.com> wrote:

> no.... no..... Joseph says it is like two locks.When you unlock one you
> lock the other? hmmmm....
>
> :-)~MIKE~(-:
>
> On Mon, Feb 16, 2015 at 7:49 PM, Michael Havens <bmike1 at gmail.com> wrote:
>
>> and then the public key everyone can see and the private one only you can
>> see?
>>
>> :-)~MIKE~(-:
>>
>> On Mon, Feb 16, 2015 at 7:45 PM, Michael Havens <bmike1 at gmail.com> wrote:
>>
>>> is a real simplified version that it is like two locks locked together
>>> and each key opens one of the locks?
>>>
>>> :-)~MIKE~(-:
>>>
>>> On Mon, Feb 9, 2015 at 7:05 PM, Joseph Sinclair <
>>> plug-discussion at stcaz.net> wrote:
>>>
>>>> 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
>>>> >
>>>>
>>>>
>>>> ---------------------------------------------------
>>>> 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
>>>>
>>>
>>>
>>
>
> ---------------------------------------------------
> 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
>

-- 
James McPhee
jmcphe at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20150216/9d894ef0/attachment.html>