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)