5
$\begingroup$

I need to analyze the output of rbsec's sslscan which reports a server's SSL/TLS configuration as reported by OpenSSL.

I'm interested in the Certificate's Signature Algorithm in particular, and I was hoping to find a complete list of possible values for this entry. During some quick tests, I saw that sslscan reports the long name for the algorithm. For example, RSA encryption with a SHA-512 hash is reported as "sha512WithRSAEncryption".

<certificate>
  <signature-algorithm>sha256WithRSAEncryption</signature-algorithm>
  ...
</certificate>

I've been trying for hours to pin down where these strings come from, and it seems that they aren't from the RFC specification for SSL (RFC 6101), but I could be wrong about that. I did find the names in OpenSSL's obj_dat.h file, however that header file contains a significant number of defined strings which are clearly not also signature algorithms.

  ...
  {"id-ppl-independent", "Independent", NID_Independent, 8, &so[4500]},
  {"RSA-SHA256", "sha256WithRSAEncryption", NID_sha256WithRSAEncryption, 9, &so[4508]},
  {"RSA-SHA384", "sha384WithRSAEncryption", NID_sha384WithRSAEncryption, 9, &so[4517]},
  {"RSA-SHA512", "sha512WithRSAEncryption", NID_sha512WithRSAEncryption, 9, &so[4526]},
  {"RSA-SHA224", "sha224WithRSAEncryption", NID_sha224WithRSAEncryption, 9, &so[4535]},
  {"SHA256", "sha256", NID_sha256, 9, &so[4544]},
  ...

Is there a list of the (OpenSSL specific?) long names for the Signature Algorithms that OpenSSL reports? Preferably one that is easily digestible for a program or human?

$\endgroup$
3
  • 1
    $\begingroup$ Relevant RFCs: 5280, 3279, 4055, 4491. These are all PKIX RFCs, which is the working group for certificates. $\endgroup$
    – SEJPM
    Sep 30, 2017 at 10:47
  • $\begingroup$ If "sha256WithRSAEncryption" is a signature algorithm, that's a miss-namer. And that could be several signature or encryption schemes (the hash used by MGF1 of RSASSA-PSS or RSAES-OAEP is not necessarily the same as the other hash, and one can use anything as MGF, and why not SHA-3, or BLAKE2). To me it looks like the question involves what does (program) actually does when (other program) tells (something), which is arguably an off-topic nightmare. $\endgroup$
    – fgrieu
    Dec 29, 2017 at 14:48
  • 1
    $\begingroup$ @fgrieu: PKCS1v1 over 20 years ago assigned `{md2,md4,md5}withRSAEncryption' as names (and OIDs in an arc belonging to RSADSI) for what was then 'RSA block type 1 signature' and is now retronymed RSASSA-PKCS1-v1_5. Even though calling signature 'encryption' is now recognized as a mistake, later revs of PKCS1 have continued this name pattern for SHA1 and SHA2 variants of that algorithm, presumably for consistency; the world is not perfect. In contrast PSS has a single OID, and the message and MGF hashes are (both) encoded in the parameters. (And the English word for this is 'misnomer'.) $\endgroup$ Jun 14, 2019 at 0:36

3 Answers 3

2
$\begingroup$

You can find a list in the bouncyCastle source code for Asn1SignatureFactory, here:

https://github.com/kerryjiang/BouncyCastle.Crypto/blob/master/Crypto/x509/X509Utilities.cs

In addition to that, you can list all registered SSL-digest-methods with the following C-Code:

#include <openssl/evp.h>
#include <openssl/objects.h>
#include <stdio.h>

void my_callback(const OBJ_NAME *obj, void *arg)
{
  printf("Digest: %s\n", obj->name);
}

int main(int argc, char *argv)
{
  void *my_arg;
  OpenSSL_add_all_digests(); //make sure they're loaded

  my_arg = NULL;
  OBJ_NAME_do_all(OBJ_NAME_TYPE_MD_METH, my_callback, my_arg);
}

The callback receives objects of type OBJ_NAME:

typedef struct obj_name_st {
    int type;
    int alias;
    const char *name;
    const char *data;
} OBJ_NAME;

You can look up the associated EVP_MD* via EVP_get_digestbyname(). This method finds a lot of things, many of which you probably don't want:

$ ./a.out
Digest: ripemd160WithRSA
Digest: ssl2-md5
Digest: sha384
Digest: sha224
Digest: SHA224
Digest: md4
Digest: sha512
Digest: RSA-SHA256
Digest: DSA-SHA
Digest: sha1WithRSAEncryption
Digest: MD5
Digest: MD4
Digest: ssl3-sha1
Digest: ripemd160
Digest: sha
Digest: SHA384
Digest: SHA1
Digest: ssl3-md5
Digest: sha256
Digest: sha384WithRSAEncryption
Digest: SHA512
Digest: DSA-SHA1-old
Digest: dsaWithSHA1
Digest: ecdsa-with-SHA1
Digest: whirlpool
Digest: RSA-RIPEMD160
Digest: rmd160
Digest: RIPEMD160
Digest: RSA-SHA1-2
Digest: RSA-SHA1
Digest: dsaWithSHA
Digest: md5WithRSAEncryption
Digest: DSS1
Digest: RSA-MD5
Digest: dsaEncryption
Digest: ripemd
Digest: md4WithRSAEncryption
Digest: DSA
Digest: sha512WithRSAEncryption
Digest: SHA
Digest: dss1
Digest: RSA-SHA224
Digest: RSA-SHA512
Digest: SHA256
Digest: md5
Digest: RSA-SHA384
Digest: sha1
Digest: sha224WithRSAEncryption
Digest: RSA-SHA
Digest: shaWithRSAEncryption
Digest: sha256WithRSAEncryption
Digest: DSA-SHA1
Digest: RSA-MD4
$\endgroup$
1
  • 1
    $\begingroup$ OpenSSL itself has support for this output now, using openssl list -digest-algorithms $\endgroup$
    – davenpcj
    Jun 13, 2019 at 20:44
1
$\begingroup$

So, the list in OpenSSL belongs to OpenSSL, and you're welcome to use that.

What's going on inside the certificates themselves is that they're using ASN.1 (Abstract Syntax Notation) and so they identify things like this using OIDs (Object Identifiers), which are a vast ("universal") tree structure of arbitrary identifiers for anything.

For example, sha256WithRSAEncryption is the usual name for OID 1.2.840.113549.1.1.11

As a result of this there's no need for any central "complete list" to exist, you should create a list that suits your own needs. If you have an OID that you don't know the name for, you can usually Google search it, since OIDs are hierarchical there is no complete list of those either of course, but it sounds like the tool you're using will emit text anyway, so just use the text.

$\endgroup$
3
  • $\begingroup$ Is there a place I can look other than OpenSSL's source to find a list of common names to start with? I get that I don't need an entirely complete list, but I was more hoping to have somewhere to start besides these handful. $\endgroup$ Aug 31, 2017 at 14:53
  • $\begingroup$ Furthermore, I think its worth noting that the tool's output that I have is the string name, and not the OID, so I have to anticipate at least the most common names. $\endgroup$ Aug 31, 2017 at 14:54
  • 1
    $\begingroup$ I suspect that "analyzing" output you don't understand by trying to match it against an arbitrary list of strings you don't understand will produce useless gibberish. You can skip that by just making up some gibberish in advance which is easier. "These handful" will represent all the signature algorithm names ordinary OpenSSL users ever have any need for. If you must have a list, I'm sure that one will be fine, the only point of my answer is to explain that it's not a "complete" list and there can't be one. $\endgroup$
    – tialaramex
    Sep 1, 2017 at 7:48
1
$\begingroup$

OpenSSL source includes a file crypto/objects/objects.txt which has a list of all the object names/oids that OpenSSL understands. It's definitely parsable; there's a perl script with it which parses the file to produce openssl's obj_dat.h header.

OpenSSL in 1.1.0 and later supports the "list" argument. openssl list -digest-algorithms

produces:

BLAKE2b512
BLAKE2s256
MD4
MD5
MD5-SHA1
MDC2
RIPEMD160
RSA-MD4 => MD4
RSA-MD5 => MD5
RSA-MDC2 => MDC2
RSA-RIPEMD160 => RIPEMD160
RSA-SHA1 => SHA1
RSA-SHA1-2 => RSA-SHA1
RSA-SHA224 => SHA224
RSA-SHA256 => SHA256
RSA-SHA384 => SHA384
RSA-SHA512 => SHA512
SHA1
SHA224
SHA256
SHA384
SHA512
BLAKE2b512
BLAKE2s256
MD4
md4WithRSAEncryption => MD4
MD5
MD5-SHA1
md5WithRSAEncryption => MD5
MDC2
mdc2WithRSA => MDC2
ripemd => RIPEMD160
RIPEMD160
ripemd160WithRSA => RIPEMD160
rmd160 => RIPEMD160
SHA1
sha1WithRSAEncryption => SHA1
SHA224
sha224WithRSAEncryption => SHA224
SHA256
sha256WithRSAEncryption => SHA256
SHA384
sha384WithRSAEncryption => SHA384
SHA512
sha512WithRSAEncryption => SHA512
ssl3-md5 => MD5
ssl3-sha1 => SHA1
whirlpool

I should note that DSA/ECDSA/EdDSA signature algorithms are conspicuously absent here, it may be they just aren't present in OpenSSL's digest algorithm list.

There's a similar list for supported public key algorithms.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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