Time by time I receive questions about alternate signature algorithms. What is the difference between them and what benefits are in an alternate signature algorithms.
As per TechNet article:
For certificates based on RSA algorithms, PKCS #1 v2.1 specifies separate object identifiers for the hash algorithm and for the asymmetric algorithm. (In PKCS #1 v.1.5, only one object identifier is used to identify both the hash and asymmetric algorithms.) In addition, if you select the alternate signature format for certificates based on RSA algorithms, an enhanced cryptographic formula is used to create the signature.
Generally speaking, alternate signature algorithm (signature format) just allows to specify additional details about how signature is constructed.
Here is a classic algorithm identifier structure for PKCS#1 v1.5:
RSAES-AlgorithmIdentifier ::= AlgorithmIdentifier { {PKCS1Algorithms} } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY OPTIONAL }
Algorithm parameters are set to NULL, so signature actually looks as follows:
Here we see a sequence that is followed by an algorithm identifier (sha1RSA) and optional parameters are set to null.
With alternate signature algorithm, the structure become a bit more complicated:
OAEP-PSSDigestAlgorithms ALGORITHM-IDENTIFIER ::= { { OID id-sha1 PARAMETERS NULL }| { OID id-sha224 PARAMETERS NULL }| { OID id-sha256 PARAMETERS NULL }| { OID id-sha384 PARAMETERS NULL }| { OID id-sha512 PARAMETERS NULL }| { OID id-sha512-224 PARAMETERS NULL }| { OID id-sha512-256 PARAMETERS NULL }, ... -- Allows for future expansion -- } HashAlgorithm ::= AlgorithmIdentifier { {OAEP-PSSDigestAlgorithms} } -- example hash algorithm for sha1: -- HashAlgorithm ::= { -- algorithm id-sha1, -- parameters SHA1Parameters : NULL -- } PKCS1MGFAlgorithms ALGORITHM-IDENTIFIER ::= { { OID id-mgf1 PARAMETERS HashAlgorithm }, ... -- Allows for future expansion -- } MaskGenAlgorithm ::= AlgorithmIdentifier { {PKCS1MGFAlgorithms} } id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 10 } -- 1.2.840.113549.1.1.10 RSAES-AlgorithmIdentifier ::= AlgorithmIdentifier { {PKCS1Algorithms} } RSASSA-PSS-params ::= SEQUENCE { hashAlgorithm [0] HashAlgorithm DEFAULT sha1, maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1, saltLength [2] INTEGER DEFAULT 20, trailerField [3] TrailerField DEFAULT trailerFieldBC } TrailerField ::= INTEGER { trailerFieldBC(1) } rSASSA-PSS-Default-Identifier RSASSA-AlgorithmIdentifier ::= { algorithm id-RSASSA-PSS, parameters RSASSA-PSS-params : { hashAlgorithm sha1, maskGenAlgorithm mgf1SHA1, saltLength 20, trailerField trailerFieldBC } } RSASSA-AlgorithmIdentifier ::= AlgorithmIdentifier { {PKCS1Algorithms} }
I just pointed the most notable parts of the ASN module which are necessary to construct alternate signature algorithm. You can see that RSASSA-AlgorithmIdentifier structure consist of:
In the ASN viewer we can see something like this:
I just labeled ASN.1 viewer nodes with a corresponding objects in the ASN module. In a given example, RSASSA-PSA algorithm uses sha256 hashing algorithm. TrailerField is absent, because it is implicitly set to 1 (other values are not defined in the current profile).
While all this is very interesting and entertaining, main question is: should I use PKCS#1 v2.1 signature formats and when? The answer is…there is no definite answer. Normally, I would suggest to avoid alternate signature format usage until it is required by a particular product even though it is very flexible. Most applications do not utilize these features and just propagate v1.5 signature to a v2.1 format and you don’t get any benefits from here. Common v1.5 standard is widely supported and there is no any security risk with it unless you are not using weak algorithms (lower than SHA1).
HTH
Post your comment:
Comments: