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 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 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 >>> >> >> >