Holger Reif <[EMAIL PROTECTED]> writes:
> The signature is as long as the modulus of key is. Thus the
> 20 bytes contain the (unsigned) hash value only. This field
> is just a octett string.
>
> The most important thing of PKCS#1 is the padding. You can
> have a look at crypto/rsa/rsa_pk1.c to verify what this
> means in actual code.
>
> Normally the signature contains only the hash and for
> verification you need the original data as well. But
> there are some techniques (not included in OpenSSL)
> that can contain the original data if there are short enough
Actually, in SSL, the situation is more complicated.
There are three situations in which SSL uses digital
signatures:
1. Verification of X.509 certificates.
2. Verification of signatures over ServerKeyExchange requests.
3. Verification of signatures over CertificateVerify messages.
As Holger indicates, in X.509 Certs, the signed data is a PKCS-1
padded (for RSA) digest of the certificate embedded in an ASN.1
sequence and encoded as a BIT STRING.
In SSL, signatures are encoded as an opaque <2^16-1>.
For ServerKeyExchange messages, the signature is a PKCS-1 (for RSA)
encoded digest of a hash of the structure, meaning that the digest is
first wrapped in a DigestInfo structure. For CertificateVerify
messages, however, the situation is different:
For RSA signatures, the data to be signed is the concatenation of
two digests, an MD5 hash and a SHA hash. The data is PKCS-1
block type 1 encoded, but the data is signed without first
wrapping it in a DigestInfo wrapper.
For DSS signatures, only the SHA digest is used and it's signed
directly.
-Ekr
--
[Eric Rescorla [EMAIL PROTECTED]]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
