private key encryption - doubts

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

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

Re: private key encryption - doubts

Quoted text here. Click to load it

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

fips186-2 has DSA and ECDSA

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

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

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

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

Anne & Lynn Wheeler | /

Re: private key encryption - doubts

Anne & Lynn Wheeler wrote:
Quoted text here. Click to load it
I havent learned the algos right now. Just trying to get a hang of
entire process. Please consider this:

1. Receive the message.
2. Compute one-way hash of it. (How do I know which method to use for
computing one way hash? Is it something that is to be agreed upon by
both the parties.)
3. Decode the signature using the public key of sender. (Is it possible
that I will come to know the private key of other person as I have
seperated the message from his private key?... Please put more light on
this and if possible explain the algo in laymans language. It will be
very kind of you?).
4. Compares the hash, if same everything is OK.


Quoted text here. Click to load it
How is the symmetric key generated? What algorithms are used?
Suppose I finally got the symmetric key decided by the originator. Do I
have to know how the key was created for continuing the encryption or
its just a key that will be used for encryption. Is the ALGO for
encrypting be same for both the parties.

What is the basic difference between RSA/DSA?
Actually I did ssh without password. I was able to do it successfully
but didnt understood how it happened. So I tried to dig into it.

The process I followed:
1. Generate a RSA key SSH1.
2. It asked for passphrase: I set it as blank (Didnt understood the
meaning of it? Enlighten the same if possible).
3. saved it on the server where I wish to connect without password.

Now this is what i understand now:

1. The remote server generates a symmetric key when I try to connect &
throws me a challenge for encoding some intial text using that
symmetric key.
2. I use my private key to decode the challenge. Encode the challenge
with symmetric key extracted and send it back.
3. Server checks the text is same and allow me to log on.
4. Server - SSH Client then use the symmetric key for communication.

Am I RIGHT....

Also I want to learn the algorithms from ground up. Please suggest some
key words for searching in GOOGLE, that will guide me. I know your time
is precious and it will be bad of me asking for so much help.

Quoted text here. Click to load it

Re: private key encryption - doubts

Quoted text here. Click to load it

... you are now passed the overview stage and into read-the-manual
stage. i already provided the URL for nist fips182 ... which goes into
detail on dsa, ecdsa, and rsa digitlal signatures (and lots of
additional details).

you should now read the detailed documentation.

with quicky use of search engine ... here is openssh /

here is reference for openSSL /

SSL2 from the netscape web site

we were aksed to consult with this small client/server startup in
menlo park that wanted to do payment transactions on their "commerce"
server. in the year we worked with them, they moved from menlo park to
mountain view and changed their name. trivia question ... who had the
rights to their new name at the time? also what corporation was
providing substantial amount of funding for the commerce server?

minor posting drift with regard to the above period

SSL3 from the netscape web site

for TLS internet standards (aka standards version of SSL)
... there is my rfc index

in the "RFCs listed by" section, click on "Term (term->RFC#)"

in the acronym fastpath, select "TLS"

transport layer security  (TLS )
 see also encryption , security
 3943 3788 3749 3734 3546 3436 3268 3207 2847 2830 2818 2817 2716
 2712 2595 2487 2246

slicking on the rfc number brings up the RFC summary. clicking on
the ".txt=nnn" filed in the RFC summary fetches the actual RFC.

with a little more searching you should be able to find detailed
descriptions of the various kinds of asymmetric cryptography and the
basic fundamentals involved (for instance ... you might start looking
for stuff about RSA at the RSA web site ... also the certicom is
possibly a place to start looking for details about elliptical curve
(asymmetrical) cryptography.

Anne & Lynn Wheeler | /

Re: private key encryption - doubts

Thanx a lot A&L. That was of great help. I have bookmarked everything
and will surely read the same to clear the basics.

Right now I have to just call WSDL SOAP methods over HTTPS. Thats
simple right now.

Just one last thing...

I wanted to know about some open source projects, small ones which I
can study & if possible contribute something.

It would be of great help.
Just wanted to know more. You guys seem to be very much into this.

Anne & Lynn Wheeler wrote:
Quoted text here. Click to load it

Re: private key encryption - doubts

Quoted text here. Click to load it

some history on charging for software (it used to be that
almost all software was open source):

Anne & Lynn Wheeler | /

Re: private key encryption - doubts

    Yogee> Hi, Alice creates a one-way hash and encrypt it with her
    Yogee> private key -> sends it to bob. Bob decrypts it with public key
(available every
    Yogee> where i guess).

1) The right place for this would be perhaps sci.crypt, or better any
   number of web or paper references on basic cryptography.

    Yogee> So Bob now knows the private key of Alice. So its no longer private.

2) Your first question should be, why do you believe this statement?

  Richard Silverman

Site Timeline