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