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