Re: Digital signature Question

[N407ER <n407er () myrealbox com>]

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...) ;)


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