On Tue, 18 Jul 2023 18:20:02 GMT, Valerie Peng <valer...@openjdk.org> wrote:
>> Instead of falling back to unpad()/decodeSignature() I suggest to try a new >> version of encodeSignature() (in addition to trying the current version of >> it) in which you omit putting the null for params into the DER encoding and >> compare the decrypted message with that, too. Accept if any of the two >> encodings matches the decrypted one, reject otherwise. This can be done in >> constant time, although it is not necessary to be constant time as the time >> of doing it does not depend on any secret. > > @ferakocz So, with this approach, we are paying the extra cost of encode > signature + pad (for the omit null case) even for impls conforming to RFC > 8017 spec. Based on the current interoperability testing, do you still feel > that this is worthwhile to do? Well, for conforming implementations we just do the first check and succeed. What I suggested was that we do the encode without null params and pad() *instead* of the fallback to unpad()decodeSignature(). As I said, this part need not be constant time (except for the byte array comparison part), but it can even be made constant time to satisfy the purists :-) at the expense of an extra encode/pad operation which is not that expensive. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14839#discussion_r1267755745
