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

[Michael Havens]

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
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20150216/838552de/attachment.html>