Home page logo
/

basics logo Security Basics mailing list archives

Re: Digital signature Question
From: N407ER <n407er () myrealbox com>
Date: Mon, 24 Nov 2003 12:24:32 -0500

Stephen Glenn wrote:
Roger

I have just been involved in an Identrus PKI accreditation process for a
major financial institution. I am also involved in the BACS (UK clearing
system) and their move to an I/p based system using PKI. As such I have had
to gen up on the whole PKI world and this is my understanding.

The data to be hashed should be visible to the user who wants to sign the
data and it should be hashed on the same machine the user is using to make
sure that the hash is actually created from the correct data.

So the hashing algorithm is run against the data and creates the hash.

The hash is then signed by the private key. This is the private key of the
of the public/private key pair used to create the certificate request
normally sent to the CA. In the Identrus world the keys are generated on a
smart card applet and the requests (a utility and an identity one) are sent
to the Participant CA for creation of the digital certificates. The
resultant Identity and Utility certificates are then stored on the smart
card in addition to the participant certificate and the Identrus Root
certificate. These certificates are included to create trust to the top of
the pyramid in this case Identrus. The private key is protected on the smart
card by a pin.

All this happens before any transactions can happen with the card.

When a user logs on to a site and is prompted to sign a piece of data for
non-repudiation or whatever reason, the user should verify that the data he
is about sign is correct and then the accredited software will create the
hash and sign it with the private key after prompting the user to enter the
pin which protects the private key. This normally happens under an SSL
session and although in the Identrus realm the utility key can be used for
session encryption most institutions still just use 128 SSL browser based
encryption.

Hope this helps it is complicated area. I may have some good slides which
may explain it better than this posting. Drop me a mail if your are
interested.

Cheers

Stephen Glenn

I think (I am not positive, so take this with a grain of salt) that PGP/GPG (unlike SSL) does not use a symmetric key. SSL does initially pass a one-time symmetric key during the handshake process which is then used to encrypt that session, as far as I know. PGP, however, simply generates a hash of the message and then encrypts it with the private key. Then anyone with your public key can decrypt the hash and verify that it validates the message. The hash is relatively small, so the size difference between the hash and the symmetric key you would use is negligable (and thus the speed difference is as well); there is no real reason to bother with two different encryption methods.

It may be different for PGP encryption (as opposed to signing), which may be more like SSL (since there would be a larger performance gain), but I dont *think* that is how it's done. I could be wrong.

Hope I helped (even if I qualified it mutiple times...) ;)


---------------------------------------------------------------------------
----------------------------------------------------------------------------


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]