1

I have a Nuxt application that needs to retrieve some information from a Spring Boot-based auth service.

Right now I sign a text message on the Nuxt app (the auth server is aware of that text message), using node-forge, and then I send it encrypted and with the signature for verification on the auth service.

The problem is that the auth service keeps telling me that the size of the signature is wrong, with a java.security.SignatureException: Signature length not correct: got 3XX but was expecting 256.

Here is the code generating the encrypted message and signature on the Nuxt side:

var md = forge.md.sha256.create();
md.update("123"); // for example purposes
var sign = pPrivateKey.sign(md);
var digestBytes = md.digest().bytes();
console.log("Signature:", sign );
console.log("Encrypted:", digestBytes);
console.log("Encrypted B64:", Buffer.from(digestBytes).toString("base64"));

var keyAuthB64Url = Buffer.from(digestBytes).toString("base64url");

var signB64Url = Buffer.from(sign).toString("base64url");

var jwt = await axios.get(process.env.URL + "/auth", { params: { encrypted: keyAuthB64Url, signature: signB64Url } });

On the auth service I have the following code:

byte[] messageBytes = Base64.getUrlDecoder().decode(encryptedMessage);
byte[] signatureBytes = Base64.getUrlDecoder().decode(signature);

Signature sign = Signature.getInstance("SHA256withRSA");

sign.initVerify(certPublicKey);

sign.update(messageBytes);

boolean verified = sign.verify(signatureBytes);

if (!verified) {
        throw new Exception("Not verified!");
}

From all the debugging I have done, it seems like the Spring Boot app has a problem with the signature generated by node-forge on the Nuxt side, with a signature generated in the Spring Boot app the verification works.

Topaco
  • 40,594
  • 4
  • 35
  • 62
Diop Saliou Alpha
  • 67
  • 6
  • 1
    The message is '123', not the hash of '123'. Since it appears you're only send the hash of message along with its signature I can only conclude that, on the Java side the confusingly named `encryptedMessage` is the hash of the message, but `Signature.update()` expects the actual message, i.e. '123'. – President James K. Polk Jul 13 '22 at 19:12
  • It is indeed the has of the message on the java side. If the actual message is what is expected that would explain why it fails... – Diop Saliou Alpha Jul 13 '22 at 22:43
  • Still got a problem with the signature bytes after changing ```encrypted``` to ```message``` and have it contain '123' instead of a digest of it. – Diop Saliou Alpha Jul 13 '22 at 23:36

1 Answers1

1

There are several issues:

  • First, the bug that was already mentioned in the comment: While the NodeJS code does not hash implicitly, the Java side does. Therefore, hashing must not be done explicitly on the Java side:

    byte[] messageBytes = "123".getBytes("utf-8");
...
sign.update(messageBytes); // Fix 1: Don't hash

  • Also, in the NodeJS code, sign() returns the data as a bytes string, which must therefore be imported into a NodeJS buffer as a 'binary':

    var keyAuthB64Url = Buffer.from(digestBytes, "binary").toString("base64url"); // Fix 2: Import via 'binary' encoding

    Without explicit specification of the encoding, a UTF-8 encoding is performed by default, which irreversibly corrupts the data.

  • And third, latin1 is implicitly used as encoding when generating the hash in the NodeJS code. Other encodings must be specified explicitly, e.g. for the common UTF-8 with utf8:

    md.update("123", "utf8"); // Fix 3: Specify the encoding

    For the example data 123 used here, this fix has no effect, which changes as soon as characters with a Unicode value larger than 0x7f are included, e.g. 123§. Note that there is little margin for error in the specification of the encoding, e.g. utf-8 would be ignored (because of the hyphen) and latin1 would be used silently.

With these fixes, verification with the Java code works.

Topaco
  • 40,594
  • 4
  • 35
  • 62
  • 1
    Here you can run both fixed codes online: [NodeJS](https://replit.com/@3hK8cL8H24hwiS7/LastingImpressiveIntroductory#index.js), [Java](https://www.jdoodle.com/iembed/v0/tcz). – Topaco Jul 14 '22 at 13:24