1
$\begingroup$

I'm reading rfc5652, there are different references of the two algorithm identifiers. For example in this ASN.1 structure:

SignerInfo ::= SEQUENCE {
        version CMSVersion,
        sid SignerIdentifier,
        digestAlgorithm DigestAlgorithmIdentifier,
        signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SignatureValue,
        unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

There're two types of identifiers: DigestAlgorithmIdentifier and SignatureAlgorithmIdentifier.

When using RSA for signing; isn't the digest algorithm represents the hash function used to compute the hash value, that's encrypted using the private key? What's the signing algorithm in this case?

Improve this question
$\endgroup$

3 Answers 3

Reset to default
2
$\begingroup$

The digest is the hash output. The digest algorithm is the hash algorithm. The digest is signed with the private key.

It's a misuse of terminology to call signing "encryption with the private key" or "decryption"'. Firstly, only RSA really allows such confusion at all since most asymmetric systems use different mathematical operations for signatures and decryption (if they allow encryption/decryption at all). Second, RSA encryption requires "padding" to work, which isn't the same as what's done in any sort of signature so the outputs are different.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ Sorry, but this doesn't answer my question. As from the IETF link, there're two different hashing algorithm, one is the digest which computes the hash value, but what about the signing algorithm, does it produce another hash (of the already-hashed value) ? And is this algorithm one the same list of the algorithms that the digest use(SHA1-SHA2-MD5...)? $\endgroup$
    – mshwf
    Sep 26, 2020 at 14:26
  • $\begingroup$ Signing involves hashing (the digest) as a substep. Step 1: hash the message. Step 2: Sign the hash. For RSA, that means apply the RSA function to create a signature: RSA(x,k,n)=x^k(mod n), with k being the private key and x being the hash. So signing is Sign(m,k,n)=RSA(H(m),k,n). Note that this scheme isn't always as good as using PSS, which uses a nonce to ensure that signing the same message twice doesn't result in the same signature. That's needed for some signcryption systems to keep IND-CCA security. $\endgroup$
    – SAI Peregrinus
    Sep 28, 2020 at 1:48
2
$\begingroup$

This is specific to PKCS7/CMS.

See rfc3370 3.2 and rfc5754 3.2, noting that the referenced versions of PKCS1v2.0 rfc2437 and 2.1 rfc3447 have been formally superseded by 2.2 rfc8017 but the content relevant here hasn't changed. Bear in mind that the original versions of both PKCS1 and PKCS7 (which became CMS) were written in the early 1990s, before it became understood that describing signature and verification as 'encrypting' and 'decrypting' the hash with the private and public keys, or 'backwards', is misleading; PKCS1 is only descriptive has been corrected but PKCS7/CMS has this mistake baked into the ASN.1 and can't be fully corrected without introducing incompatibility.

For "RSA" signature, more exactly RSASSA-PKCS1-v1_5 from PKCS1v2.0 up, with SHA-1 the 'digest' OID is 1.3.14.3.2.26 and the 'signature' OID is 1.2.840.113549.1.1.5. For e.g. SHA-256 they are 2.16.840.1.101.3.4.2.1 and 1.2.840.113549.1.1.11. Although represented by two OIDs in different parts of the message, these actually use the standard hash,pad,modexp scheme with only one hash operation. Don't use MD5, it's broken for collision and thus signature in any setting where the adversary can affect the data (e.g. certificates), so as a result people no longer trust it for anything. SHA-1 also is broken (more recently, see other Qs and https://shattered.io) for 'high-resource' attackers like a government or google, and most people have stopped trusting it.

Improve this answer
$\endgroup$
0
$\begingroup$

At a high level, the Digest Algorithm would specify what algo is used to calculate the HASH eg: MD5, SHA1, SHA256, SHA384 etc.

The Signature Algorithm would specify what signing algorithm is to be used eg: ECDSA, RSA etc.

However, in most cases the DigestAlgorithm is tightly related to the Signature Algorithm so there may be duplicated information eg: the DigestAlgorithm OID may state SHA256 and the SignatureAlgorithm OID would be ecdsaWithSHA256

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.