On 22 January 2014 22:40, Dave Thompson <dthomp...@prinpay.com> wrote:
> The general public-key sign and verify processes are: > > S1. compute hash of data (or for CMS, hash of data-hash plus some other > bits) > > S2. generate signature for hash S1 using private key (RSA, DSA, or ECDSA) > > S3. send signature with or linked to data, and certs if needed > > V0. receive signature and data, and receive or otherwise obtain certs if > used > > V1. compute hash of data (or for CMS as above) – should always be same as S1 > > V2. verify received signature for hash V1 using public key > > > > For RSA only (and with minor exceptions) S2 breaks down as: > > S21. encode hashvalue plus OID for hash in ASN.1 > > S22. “pad” S21, classically PKCS#1(v1.5) which truly just pads; an > alternative > > now is PSS which mixes up S21 in a complicated way but it still called > padding > > S23. modexp S22 to private exponent d mod n > > and V2 breaks down as: > > V21. modexp signature to public exponent d mod n, which recovers S22 > > V22. “unpad” V21 using the same method as S22, which recovers S21 > > V23. un-encode V22=S21 and match to expected value and OID > > > > (old) EVP_Sign/Verify* does all of these steps, although for 2-level hashing Good answer! Just for clarity, it does not do S3 or V0. Sending and receiving the data is up to you if you use these functions. Matt ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
