farily acccurate.
http://www.cs.rutgers.edu/pgp/pgpdoc2/pgp-better-uuencode.html
On Mon, Feb 16, 2015 at 8:55 PM, Michael Havens <
bmike1@gmail.com> 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 <cryptworks@gmail.com>
> 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 <bmike1@gmail.com> 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" <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
>>>>
>>>
>>>
>>> ---------------------------------------------------
>>> 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
---------------------------------------------------
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
(text/plain)