# How to name a signature algorithm that has no hashed component

I have an API-based service that digitally signs messages with RSA or ECDSA (system decides during runtime). The input is base64 encoded SHA-256 hash and the output is:

1. signature of this hash
2. signature algorithm, something like: "SHA256WithRSAEncryption" - to indicate if RSA or ECDSA was used by the system.

I now want to add functionality to also allow authentication (using a different certificate pair). For authentication, I don't want users to hash anything, I want the clients to generate random bytes with length (256/8)=32 and pass me the Base64 encoded version of this.

Now I have a problem how to correctly name the signature algorithm since the actual input is not a hash but random bytes. I was thinking like "Raw256WithRSAEncryption" to indicate that it wasn't a hash. But then I started to think if there was some hash algorithm that would actually return the thing itself, something like "Nohash256WithRSAEncryption".

• Two things: First, to me it is still unclear what you are actually trying to do. Second "SHA256WithRSAEncryption" is already a terrible name (I know you did not come up with it.) since nothing is being encrypted in a signature algorithm. – Maeher Dec 12 '18 at 14:51

## 1 Answer

If the RSA signatures you are doing are the ones standardly identified by the names you reference, corresponding to OIDs 1.2.840.113549.1.1.{2,4,5,11-16}, namely the scheme that was 'block type 1' in PKCS1v1 and retronymed RSASSA-PKCS1-v1_5 in PKCS1v2, it requires the hash algorithm identifier to be included in the padding; see step 2 of 9.2 in RFC8017 and the Notes on the following page, or the equivalent sections in earlier versions. Thus you cannot have an v1_5 signature which does not identify a hash algorithm, even if you didn't actually use that hash in computing the signature. (This is why openssl pkeyutl -sign for RSA with padding specified or defaulted as pkcs1 requires you to specify -pkeyopt digest:name to get the correct result even though it doesn't actually do the hash.)

For ECDSA (and DSA) although the standards (FIPS 186, X9.62, SEC1) require using a suitable hash, it is technically possible for the algorithms to generate and verify signatures using any bitstring of the correct size (not necessarily from any hash algorithm). FWIW, the usual Java cryptoprovider(s) -- Sun/Oracle/OpenJDK SUN and SunEC -- provide these as "NONEwithDSA" and "NONEwithECDSA" (casing only nominal, because in JCA algorithm names are case-insensitive), and BouncyCastle provides nominal "NONEWITHDSA" and "NONEWITHECDSA" with the former also aliased as "RAWDSA"; these do not have corresponding OIDs. IBM might be different, as might Android.

(Bouncy actually also provides "RSA" aliased as "NONEWITHRSA" and "RAWRSA", but as above they produce nonstandard and noninteroperable results, unless you handle the DigestInfo encoding yourself. And SunJCE and Bouncy support as a Cipher (not Signature) different versions of the semantically wrong but traditional "RSA encryption with private key".)