That is where I was befuddled. I didn't realize that the public/private keys belonged to the same person. So when we get a message with a key on it that is the public key and everyone has access to it and that will encrypt/decrypt a message if we know how to use it.. And then originator of the key has the private key to do the opposite as was done to the message before it was sent.

:-)~MIKE~(-:

On Mon, Feb 16, 2015 at 8:18 PM, Stephen Partington <cryptworks@gmail.com> wrote:

Stolen but relevant.

The Public and Private key pair comprise of two uniquely related cryptographic keys (basically long random numbers). Below is an example of a Public Key:

3048 0241 00C9 18FA CF8D EB2D EFD5 FD37 89B9 E069 EA97 FC20 5E35 F577 EE31 C4FB C6E4 4811 7D86 BC8F BAFA 362F 922B F01B 2F40 C744 2654 C0DD 2881 D673 CA2B 4003 C266 E2CD CB02 0301 0001

The Public Key is what its name suggests - Public. It is made available to everyone via a publicly accessible repository or directory. On the other hand, the Private Key must remain confidential to its respective owner.

Because the key pair is mathematically related, whatever is encrypted with a Public Key may only be decrypted by its corresponding Private Key and vice versa.

For example, if Bob wants to send sensitive data to Alice, and wants to be sure that only Alice may be able to read it, he will encrypt the data with Alice's Public Key. Only Alice has access to her corresponding Private Key and as a result is the only person with the capability of decrypting the encrypted data back into its original form.

As only Alice has access to her Private Key, it is possible that only Alice can decrypt the encrypted data. Even if someone else gains access to the encrypted data, it will remain confidential as they should not have access to Alice's Private Key.

From https://www.comodo.com/resources/small-business/digital-certificates2.php

On Feb 16, 2015 7:57 PM, "Michael Havens" <bmike1@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@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@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@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@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@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@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@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss