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
(text/plain)