ACCEPTED_HASH_DIGEST_ALGORITHMS support sha3?

[MorganReid]

As shown in the figure, I hash the signature file on the client side by specifying the attribute, and then call the signer to sign.

In the past, we signed and verified with the following commands

openssl rsautl -raw -sign -inkey ./keys/private.key -in binary.file > binary.file.sig

openssl rsautl -raw -verify -in binary.file.sig -inkey keys/public.key -pubin > dec.binary.file

cmp binary.file dec.binary.file

and now we want to use signserver for signing, and the verification remains the same. Now there are 2 problems.
The first is the signature file must be sha3-256, and then I modify this attribute and find that it is not supported. Is signserver currently not supported? Or is there another way to configure it?
The second is the -raw parameter in the openssl command will have any effect on the configuration of the signer?

[netmackan]

There are two ways to use the PlainSigner with what we call Client-side hashing, see: https://doc.primekey.com/signserver/signserver-reference/client-side-hashing#ClientSideHashing-PlainSignatures.

With the "Explicitly using Request Metadata Properties" that is when you need the ACCEPTED_HASH_DIGEST_ALGORITHMS and some more request properties. This mode could be the easiest to use as besides the properties the data you send it would be the hash without any special encoding. This only works for currently supported hash algorithms: SHA1, SHA-256, SHA-384, SHA-512.

However, the other mode "Implicitly and with Encoding Depending on Algorithm" should work with all algorithms, but now it is up to you to format the signature input accordingly. For RSASSA-PKCS1_v1.5 it means that the input needs to be the DER encoded DigestInfo structure from RFC #3447 page 42 containing the OID of the hash algorithm and the hash value. If this is what you already have in binary.file, I guess you are good to go and to use that.

I am not aware exactly what the rsautl commands does. Maybe the raw flag would mean "no padding" in which case that is probably different then what you get from the PlainSigner which for NONEwithRSA would use PKCS1 padding (or using NONEwithRSAandMGF1 which uses PSS padding).

[MorganReid]

Thank you very much for your reply, I followed your method, but the problem is still not resolved, the following is my related operation.
1：I integrate signserver in code by using ISigningAndValidation

//Construct signserver

    protected SignService() {
        String signServerHost = System.getProperty("signServerHost");
        int signServerPort = Integer.getInteger("signServerPort");
        signServer = new SigningAndValidationWS(signServerHost, signServerPort, true);
    }

//Raw sign

    public SignFileResponse rawSign(byte[] bytesUnsigned) {
        ProcessRequest processRequest = (new GenericSignRequest(ThreadLocalRandom.current().nextInt(), bytesUnsigned));
        RemoteRequestContext remoteRequestContext = new RemoteRequestContext();
        RequestMetadata metadata = new RequestMetadata();
        metadata.put("USING_CLIENTSUPPLIED_HASH", "false");
        remoteRequestContext.setMetadata(metadata);
        ProcessResponse processResponse = signServer.process("zynqSigner", processRequest, remoteRequestContext);

2：Related configuration of zynqSigner

3：binaryFile
This file is generated locally. the binary file is 512bytes, use sha-384 to generate 48bytes, and use SHA3 PKCS#1v1.5 Padding to 512bytes.
4：result

5：Question
The binary.file is 512bytes, and the default key is rsa4096. According to the exception information, the length should be exceeded. Is this caused by signerver padding when signing?If yes, is the padding of SHA2 PKCS#1v1.5 Padding or SHA3 PKCS#1v1.5 Padding or others? Do we have a way to change the padding or cancel the padding? Or does signserver provide a simple rsa encryption and decryption function?
I have tried for a long time locally and still have no success, thank you very much for your answer.

[netmackan]

5: Actually, the padding is done by the signer so this might be why it believes your input is too large. This is not currently clear in the documentation but has been clarified like this in the next version:

NONEwithRSA (RSASSA-PKCS1_v1.5):
The input should be a DER encoded DigestInfo structure. Please refer to RFC 3447 and specifically page 42 for examples on the exact encoding.

So this means that you should not apply any padding and instead just provide the DigestInfo structure (DER encoded). On page 42 is the exact bytes expected for some hash algorithms but it should probably work to construct that yourself and instead use SHA3.

Hope this helps. Let us know how it works out.