We saw some issues when using Swift-JWT with the ES512 signer, which uses the BlueECC crypto underneath. The issue was, that the generated signature is sometimes invalid, producing r and s values with 65 Bytes instead of 66 Bytes in ~0,1% of the cases.
By adding the following test, you see that the verification fails sometimes:
func test_SignatureGeneration() throws {
let secp521r1Key = try ECPrivateKey.make(for: .secp521r1)
let secp521r1PubKey = try secp521r1Key.extractPublicKey()
do {
for i in 1 ..< 10000 {
let signature521 = try "Hello world".sign(with: secp521r1Key)
XCTAssertEqual(signature521.r.count, 66) // those two assertions
XCTAssertEqual(signature521.s.count, 66) // will sometimes fail
let copiedSignature = try ECSignature(r: signature521.r, s: signature521.s)
let verified521 = copiedSignature.verify(plaintext: "Hello world", using: secp521r1PubKey)
XCTAssertTrue(verified521)
print("\(i) done")
}
} catch {
return XCTFail("test_SignatureGeneration failed: \(error)")
}
}
During debugging, I found that in the asn1ToRSSig method, the returned trimmed r and s values sometimes have 65 Bytes instead of 66. However, I was unsuccessful just padding them with null bytes.
The error must be somewhere in the transformation from the original asn1 to the rs format, because when using asn1 in the test above directly:
let copiedSignature = try ECSignature(asn1: signature521.asn1)
the error does not occur.
Note: I was unable to reproduce this on a different curve (e.g. es384). I guess this is due to the nature of the 521 bit curve.
We saw some issues when using Swift-JWT with the
ES512signer, which uses the BlueECC crypto underneath. The issue was, that the generated signature is sometimes invalid, producingrandsvalues with 65 Bytes instead of 66 Bytes in ~0,1% of the cases.By adding the following test, you see that the verification fails sometimes:
During debugging, I found that in the
asn1ToRSSigmethod, the returned trimmedrandsvalues sometimes have 65 Bytes instead of 66. However, I was unsuccessful just padding them with null bytes.The error must be somewhere in the transformation from the original
asn1to thersformat, because when usingasn1in the test above directly:the error does not occur.
Note: I was unable to reproduce this on a different curve (e.g.
es384). I guess this is due to the nature of the 521 bit curve.