Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CC.RSA.sign output cannot be verified openssl backed libraries #59

Open
mikehouse opened this issue Apr 13, 2020 · 4 comments
Open

CC.RSA.sign output cannot be verified openssl backed libraries #59

mikehouse opened this issue Apr 13, 2020 · 4 comments

Comments

@mikehouse
Copy link

Hello, awesome work, thanks a lot!

Have found strange behaviour, I'm not a cryptographer and don't know where to dig to. A signature created with .pss padding and some salt false verified on backend with Python/Ruby but works vice verse.

iOS:

let signature = try CC.RSA.sign(dataSign, derKey: privateKey, padding: .pss, digest: .sha384, saltLen: 16)

Backend Python returns false for this signature

public_key.verify(signature, dataSign, padding.PSS(mgf=padding.MGF1(SHA384())), salt_length=16), SHA384())

The same verification tried on Ruby

public_key.verify_pss("SHA384", signature, dataSign, salt_length: 16, mgf1_hash: "SHA384")

also gives false result.

But when create signature on backend side

Python

signature = private_key.sign(dataSign, PSS(mgf=padding.MGF1(SHA384(), salt_length=16), SHA384())

Ruby

signature  = private_key.sign_pss("SHA384", dataSign, salt_length: 16, mgf1_hash: "SHA384")

Then on iOS side

try CC.RSA.verify(dataSign, derKey: publicKey, padding: .pss, digest: .sha384, saltLen: 16, signedData: signature)

It returns true.

Am I missing something ? Or CommonCrypto and OpenSSL work different for signature creation when using pss + salt ? As using padding pkcs15 all works as expected.

Thank you one more time for your great work !

@brentvvosselen
Copy link

Hi @mikehouse ,

We seem to be having the same issue since we've updated our codebase to work with XCode 11. I've written some tests in XCode 10.1 with salt disabled (lengt = 0) and they return a different result in XCode 11.

Until this moment, we're still looking for a solution. I am not sure if you have found any and/or able to share?

@brentvvosselen
Copy link

brentvvosselen commented May 20, 2020

Small update here from my side.
We were able to resolve the issue by building against Swift 5 as we were still building against Swift 4.
We updated our project to use Swift 5. But we also needed the version of SwCrypt found in this PR (#51). After targeting our pod to that specific commit our issue was resolved.

@yen936
Copy link

yen936 commented Feb 19, 2021

@brentvvosselen I am receiving the same verification failure as @mikehouse under the exact same scenario.

Also not a cryptographer--at all--but is it related to the set salt value applied on the iOS side?

SwCrypt

public enum AsymmetricSAPadding: UInt32 {
			case pkcs15 = 1001
			case pss = 1002
		}

Also thanks for making this and looking into it!

public_key.verify(signature_decoded, input_string.encode('utf-8'), padding.PSS( mgf=padding.MGF1(hashes.SHA256()), salt_length=16,), hashes.SHA256() )
let signature = (try? CC.RSA.sign(Data(inputString.utf8), derKey: privateKey, padding: .pss, digest: .sha256, saltLen: 16))!

returns cryptography.exceptions.InvalidSignature

@yen936
Copy link

yen936 commented Jan 22, 2023

Small update here from my side. We were able to resolve the issue by building against Swift 5 as we were still building against Swift 4. We updated our project to use Swift 5. But we also needed the version of SwCrypt found in this PR (#51). After targeting our pod to that specific commit our issue was resolved.

I am building against Swift 5 and PR (#51) has been merged. However I am still having the same issue-- cryptography.exceptions.InvalidSignature. Could @brentvvosselen you provide some more info on how you solved this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants