Bug 27603 - verify() can fail either by returning flase or rejecting with an error, inconsistent which is used

[mwatson2]

Bug 27603:

There are two ways for crypto.subtle.verify() to fail verification:

(1) Resolve the promise with false
(2) Reject the promise with an error

There are inconsistencies between algorithms on which approach is chosen, and there are also implementation complexities that arise from the distinctions.

For instance:

• In the case of ECDSA the spec treats all verification failures the same way, but returning "false".
• In the case of RSASSA-PKCS1-v1_5 the spec says to reject with an OperationError "If performing the operation results in an error".

I haven't run a full set of tests yet, however I am uncertain that the popular crypto libraries consistently distinguish errors for RSASSA-... and RSA-PSS in the manner required.

[mwatson2]

I think all three should consistently offer the possibility to throw an error. ECDSA doesn't have this at present.

We should check whether the underlying crypto specifications are clear about what is an error and then we will see during testing whether implementations are compliant.

[mwatson2]

Pull Request #102

[jimsch]

I am not sure that I think this is a good idea. I believe that I would prefer to move in the opposite direction of just returning true/false as as result if there is an error in the operation.

The ability for code to distinguish between an incorrect hash and a bad padding in RSA is a classic attack. For this reason I believe that the code should only return true/false.

[mwatson2]

Any comments on @jimsch's suggestion ?

[mwatson2]

Discussed on 7/11 call. Suggest making this change: always return false if the signature is not valid.

[harryhalpin]

I concur with @jimsch here, let's keep it true/false if the signature is rejected.

[mwatson2]

New PR #117