farily acccurate. http://www.cs.rutgers.edu/pgp/pgpdoc2/pgp-better-uuencode.html On Mon, Feb 16, 2015 at 8:55 PM, Michael Havens wrote: > Please tell me of the accuracy of this statement: > You don't run the keys on emails rather you run the keys over data you may > send as an attachment. > > :-)~MIKE~(-: > > On Mon, Feb 16, 2015 at 8:35 PM, Stephen Partington > wrote: > >> The public key is meant to be available to sign data for that person. you >> do this so they can un-encrypt the data but they know it was signed. and >> only they can un-encrypt that data. >> >> On Mon, Feb 16, 2015 at 8:28 PM, Michael Havens wrote: >> >>> 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" 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 >>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------- >>>>> 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 >>> >> >> >> >> -- >> A mouse trap, placed on top of your alarm clock, will prevent you from >> rolling over and going back to sleep after you hit the snooze button. >> >> Stephen >> >> >> --------------------------------------------------- >> 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 > -- A mouse trap, placed on top of your alarm clock, will prevent you from rolling over and going back to sleep after you hit the snooze button. Stephen