couple more Q's on basic public key encryption techniques

From: xz (jasonshohet_at_gmail.com)
Date: 05/02/05 

Date: 2 May 2005 11:25:38 -0700

Thanks to Greg Rose & Mike Amling for helping me with my previous
question. I digested what they had to say, and feel I've progressed a
bit here. If I may, I'd like to give some of my short notes on key
encryption, I guess I'm kind of centering on basic encryption
techniques that could be used in RSA etc. The parts that are
capitalized are my questions -- where I'm still confused. Then at the
bottom i paraphrased my questions again:

1. Sender encrypts message w/ receiver's public key ==
confidentiality.
Prevents evesdropping w/o having to use symmetric keys, since only
receiver's private key can 'unlock the box'. But if a cracker
did get in, we wouldn't have a mechanism to know that he tampered
with the data. So possible data-integrity issues. #3 addresses that.

2. Sender encrpts message w/ his own private key == nonrepudiation.
Receiver decrypts it w/ sender's public key (I GUESS IT GOES ALONG
FOR THE RIDE, IN THE MESSAGE?). This proves who sent it since only
sender's public key decrypts it. But message is not confidential -
anyone can eavesdrop since sender's public key is readily available
to 'unlock the box'.

3. Sender creates a message digest & encrypts it w/ his own private key
== digital signature (non-repudiation, & ensures data integrity too).
 As receiver decrypts it w/ sender's public key, he sees the digest
hash matches the message hash. This proves message was unaltered, as
any alteration results in a different hash when compared to the
original message hash. This is basically doing what #2 above does, but
provides for data integrity as well.

4
a. Sender creates message digest & encrypts it w/ his own private
key.
b. encrypts message w/ a symmetric key
c. encrypts symmetric key using the receiver's public key

This does everything. a == digital signature b & c == confidentiality
 So this addresses confidentiality + non-repudiation + data integrity
all together. Only the receiver's private key can decrypt the
message, so its confidential. Once he decrypts the outer shell with
the public key, he sees its encrypted inside with a symmetric key --
this makes it non-repudable since the symmetric key only comes from 1
person?? (I AM GUESSING HERE, I DON'T UNDERSTAND WHY THE SYMETRIC KEY
IS INVOLVED HERE AT ALL).
Once he decrypts it again -- this time with the symmetric key-- he then
uses the sender's public key to decrypt the message digest -
there's the digital signature part which ensures data integrity.

                 &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
OK as you see I'm a bit confused on the mechanism for transporting the
public key (the comment in #2). And in #4 above, I'm very confused on
the need to stick that symmetric key in there (step 4b). I would think
the sender could simply take the message digest + message, and encrypt
it all with the receiver's public key. That gives non-repudiation and
confidentiality right there. Why this symmetric key step in the
middle? Thanks, and I appreciate all the help!

Relevant Pages

  • RE: Confused by CryptoAPI
    ... the server should not sign the KEY itself. ... would be able to decrypt it and recover the negotiated ... You use CryptImportKey to get a handle for the server's public key. ... you don't "encrypt" your symmetric key to be sent to the server; ...
    (microsoft.public.platformsdk.security)
  • Re: Encrypt a UsernameToken Authenticated WSE Response
    ... You can dictionary attack the pw digest pretty easy in the UT to get the pw. ... you can generate the symmetric key as all needed info ... > and is just used to generate the session key to encrypt. ... >> username and passwort und the data is symmetric encrypted, ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: public private key, 3DES
    ... When you want to generate a persistent symmetric key, ... normally derive it from a passphrase and initialization vector. ... key and encrypts passphrase, IV, etc using Y's public key. ... The private key is not to be distributed or saved, ...
    (microsoft.public.dotnet.security)
  • Re: Questions about s/mime, CryptEncryptMessage & CryptMsgOpenToEncode
    ... how does it encrypt the message using multiple recipient keys ... to single public key. ... that symmetric key is used to bulk-encrypted the content data ... key of EACH of the recipients, so if you have 3 recipients, then the same ...
    (microsoft.public.platformsdk.security)
  • Confused by CryptoAPI
    ... Client asks in clear for a public key from server, ... Now client and server communicate over the symmetric key generated ...
    (microsoft.public.platformsdk.security)