Re: private key encryption - doubts

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 06/01/05 

Date: Wed, 01 Jun 2005 09:59:12 -0600

"Yogee" <mahayogee@gmail.com> writes:
> Alice creates a one-way hash and encrypt it with her private key
> ->sends it to bob. Bob decrypts it with public key (available every
> where i guess). So Bob now knows the private key of Alice. So its no
> longer private.
>
> Whats the trick in this. I think one can encode a message using public
> key but only one having private key can decript it.
>
> I need to know what exactly is a digital signature. A one-way hash and
> digest.

asymmetric cryptography uses a pair of keys, what one encodes, the
other decodes (as opposed of symmetrical cryptography that uses the
same symmetric key for both encryption and decryption).

there is a business process that defines one of asymmetric
cryptography key pair as "public" and makes it generally available,
the other of the key pair is designated "private" and consistantly
kept confidential and never divulged.

in the digital signature business process ... a hash of a message is
computed and encoded with the private key. the message and the digital
signature (encoded hash) is transmitted. the recipient recomputes the
hash of the message and decodes the digital signature with the
(corresponding) public key and then compares the two hashes. if the
two hashes are the same, then the recipient

1) knows the message hasn't been modified in transit

2) implies "something you have" authentication about the originator,
aka that the originator has access to and use of the corresponding
private key

from 3-factor authentication paradigm

* something you have
* something you know
* something you are

verification of a digital signature implies "something you have"
authentication regarding the originator ... that they have access to
and use of the corresponding private key.

in the purely digital signature verification case, the actual message
isn't necessarily encrypted/encoded. when there is a requirement to
also encrypt/encode the message ... frequently a randomly generated
symmetric key is created and actually encrypts the message
(symmetrical key encryption tends to be much more efficient than
asymmetrical key encryption). In the situation for both encrypting and
digitally signing the message ... the originator transmits the
encrypted message (with the randomly generate symmetric key), the
symmetric key encoded with the recipients public key, and the digital
signature (hash encoded with the originator's private key). The
recipient can verify the digital signature with the originator's
public key. The recipient then can decode the symmetric key (which has
been encoded with the recipient's public key) with their private
key. Having decoded the symmetric key with their private key, the
recipient can use the decoded symmetric key to decrypt the actual
message.

fips186-2 has DSA and ECDSA
http://csrc.nist.gov/cryptval/dss.htm

which is definition of public/private key pairs for digital signature
process only. in DSA/ECDSA, the hash and a randomly generated number
are combined and encoded, resulting in two values (two consecutive
digital signatures encodings of the same message will result in
different digital signature values) ... think of it as somewhat two
equations in two unknowns. DSA/ECDSA have been vulnerable to weak
random number generators which can expose the private key (quality
random numbers generation is essential to DSA/ECDSA digital signature
operation).

in the past, most hardware tokens have had very inadequate random
number generators. as a result you've seen such hardware tokens
deployed with RSA-based digital signature for authentication. The RSA
key pairs would be generated externally (using quality ranodm number
generator) and injected into the hardware token. With the advent of
hardware tokens with quality random number generation ... you can use
the random number generator for both on-token key pair generation as
well as DSA/ECDSA digital signature operations.

shared secrets and pin/password based authentication systems
http://www.garlic.com/~lynn/subpubkey.html#secrets

have the issue that the originator and the recipient both have access
to the same value ... and therefor the recipient can also use the
value to impersonate the originator. as a result, you tend to have a
requirement that such infrastructures require a unique
pin/password/key for every unique security domain. As a result there
is a huge proliferation in the number of shared secrets that an
individual has to remember.

In the digital signature scenario, only the value that is used to
verify the digital signature is ever divulged (which can't be used to
impersonate the originator). The private key which is used to
originate digital signatures is never divulged and is only available
to the specific originator (the vulnerability is any compromise of the
originator's private key).

there has been a lot published PKI, digital certificate based
public/private key business processes.

there is a lot less published on certificateless public/private
key business process
http://www.garlic.com/~lynn/subpubkey.html#certless

although typical ssh deployments of public/private key are
certificateless based. 

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Relevant Pages

  • Re: private key encryption - doubts
    ... So Bob now knows the private key of Alice. ... > same symmetric key for both encryption and decryption). ... > in the digital signature business process ... ...
    (comp.security.ssh)
  • Re: Approval Question
    ... a digital signature is just a number which is ... - encrypt that hash with the author's private key; ...
    (microsoft.public.access.security)
  • RE: integrity and mail encryption
    ... I gave my private key to somebody else. ... > so a public key infra-structure by itself does not provide ... > the corresponding private key can make a digital signature. ... you encrypt this hash with your private key. ...
    (Security-Basics)
  • RE: Signing before Encryption and Signing after Encryption
    ... If both asymmetric keys are used, the private key needs to be ... This only works if the encryption is NOT transitive, ... If the signing is done over the whole message and not just the ... hash of the message with your private key. ...
    (Security-Basics)
  • Re: usb token
    ... a digital signature is an encryption of the ... >hash. ... calculating a hash you can drop the data blocks you've already used for ...
    (comp.security.misc)