On Thu, 27 Jul 2023 20:42:37 GMT, Valerie Peng wrote:
>> This change refactors the RSAPadding class to return an output record
>> containing the status instead of relying on exception object to indicate a
>> failure.
>>
>> Thanks in advance for review~
>> Valerie
>
> Valerie Peng has updated t
On Thu, 27 Jul 2023 20:35:42 GMT, Valerie Peng wrote:
>> I checked back the specification back to RFC 2437, released on October 1998,
>> which requires to encode NULL parameters as well. As the update to keep the
>> consistency is not trivial, I may just remove it and see if it could be a
>>
On Thu, 27 Jul 2023 20:42:37 GMT, Valerie Peng wrote:
>> This change refactors the RSAPadding class to return an output record
>> containing the status instead of relying on exception object to indicate a
>> failure.
>>
>> Thanks in advance for review~
>> Valerie
>
> Valerie Peng has updated t
> This change refactors the RSAPadding class to return an output record
> containing the status instead of relying on exception object to indicate a
> failure.
>
> Thanks in advance for review~
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since t
On Tue, 25 Jul 2023 05:29:41 GMT, Xue-Lei Andrew Fan wrote:
>> Max is on vacation and may not see your question for a while...
>> IIRC, the inconsistency (NULL vs omission) goes way back. As time goes on,
>> this may no longer be an issue as spec is clarified and vendors update their
>> impleme
On Mon, 24 Jul 2023 19:58:34 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/sun/security/rsa/RSASignature.java line 227:
>>
>>> 225: byte[] padded2 = padding.pad(encoded2);
>>> 226: return MessageDigest.isEqual(padded2, decrypted);
>>> 227: }
On Thu, 20 Jul 2023 05:06:11 GMT, Xue-Lei Andrew Fan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update to address review feedbacks
>
> src/java.base/share/classes/sun/security/rsa/RSASignature.java line 227:
>
On Thu, 20 Jul 2023 00:39:08 GMT, Valerie Peng wrote:
>> This change refactors the RSAPadding class to return an output record
>> containing the status instead of relying on exception object to indicate a
>> failure.
>>
>> Thanks in advance for review~
>> Valerie
>
> Valerie Peng has updated t
> This change refactors the RSAPadding class to return an output record
> containing the status instead of relying on exception object to indicate a
> failure.
>
> Thanks in advance for review~
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since t
On Wed, 19 Jul 2023 08:46:53 GMT, Ferenc Rakoczi wrote:
>> @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
>> tha
On Tue, 18 Jul 2023 18:20:02 GMT, Valerie Peng 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
>> c
On Thu, 13 Jul 2023 09:58:34 GMT, Ferenc Rakoczi wrote:
>> src/java.base/share/classes/sun/security/rsa/RSASignature.java line 231:
>>
>>> 229: RSAUtil.decodeSignature(digestOID,
>>> unpadded));
>>> 230: }
>>> 231: }
>>
>> I understand wh
On Thu, 13 Jul 2023 04:35:31 GMT, Xue-Lei Andrew Fan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review feedbacks, e.g. Removed RSAPadding.Output and use byte[] as
>> before.
>
> src/java.base/share/cl
On Thu, 13 Jul 2023 09:58:34 GMT, Ferenc Rakoczi wrote:
>> src/java.base/share/classes/sun/security/rsa/RSASignature.java line 231:
>>
>>> 229: RSAUtil.decodeSignature(digestOID,
>>> unpadded));
>>> 230: }
>>> 231: }
>>
>> I understand wh
On Tue, 18 Jul 2023 10:46:52 GMT, Ferenc Rakoczi wrote:
>> Yes, BadPaddingException is still thrown by RSACore class.
>
> That exception is thrown by RSACore.parseMsg() if the message is larger than
> the modulus. I think it is at least debatable whether it should be a
> BadPaddingException. I
On Mon, 17 Jul 2023 23:06:57 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/sun/security/rsa/RSASignature.java line 233:
>>
>>> 231: }
>>> 232: return status;
>>> 233: } catch (javax.crypto.BadPaddingException e) {
>>
>> Can this exception still be throw
On Thu, 13 Jul 2023 11:31:40 GMT, Ferenc Rakoczi wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review feedbacks, e.g. Removed RSAPadding.Output and use byte[] as
>> before.
>
> src/java.base/share/classe
On Fri, 14 Jul 2023 20:08:54 GMT, Sean Mullan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review feedbacks, e.g. Removed RSAPadding.Output and use byte[] as
>> before.
>
> src/java.base/share/classes/s
On Thu, 13 Jul 2023 04:25:19 GMT, Xue-Lei Andrew Fan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review feedbacks, e.g. Removed RSAPadding.Output and use byte[] as
>> before.
>
> src/java.base/share/cl
On Wed, 12 Jul 2023 23:12:18 GMT, Valerie Peng wrote:
>> This change refactors the RSAPadding class to return an output record
>> containing the status instead of relying on exception object to indicate a
>> failure.
>>
>> Thanks in advance for review~
>> Valerie
>
> Valerie Peng has updated t
On Fri, 14 Jul 2023 05:06:14 GMT, Anthony Scarpino
wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review feedbacks, e.g. Removed RSAPadding.Output and use byte[] as
>> before.
>
> src/java.base/share/cla
On Wed, 12 Jul 2023 23:12:18 GMT, Valerie Peng wrote:
>> This change refactors the RSAPadding class to return an output record
>> containing the status instead of relying on exception object to indicate a
>> failure.
>>
>> Thanks in advance for review~
>> Valerie
>
> Valerie Peng has updated t
On Wed, 12 Jul 2023 23:12:18 GMT, Valerie Peng wrote:
>> This change refactors the RSAPadding class to return an output record
>> containing the status instead of relying on exception object to indicate a
>> failure.
>>
>> Thanks in advance for review~
>> Valerie
>
> Valerie Peng has updated t
On Thu, 13 Jul 2023 04:35:31 GMT, Xue-Lei Andrew Fan wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Address review feedbacks, e.g. Removed RSAPadding.Output and use byte[] as
>> before.
>
> src/java.base/share/cl
On Wed, 12 Jul 2023 23:12:18 GMT, Valerie Peng wrote:
>> This change refactors the RSAPadding class to return an output record
>> containing the status instead of relying on exception object to indicate a
>> failure.
>>
>> Thanks in advance for review~
>> Valerie
>
> Valerie Peng has updated t
> This change refactors the RSAPadding class to return an output record
> containing the status instead of relying on exception object to indicate a
> failure.
>
> Thanks in advance for review~
> Valerie
Valerie Peng has updated the pull request incrementally with one additional
commit since t
On Wed, 12 Jul 2023 16:58:20 GMT, Xue-Lei Andrew Fan wrote:
>> This change refactors the RSAPadding class to return an output record
>> containing the status instead of relying on exception object to indicate a
>> failure.
>>
>> Thanks in advance for review~
>> Valerie
>
> src/java.base/share/
On Wed, 12 Jul 2023 16:46:08 GMT, Xue-Lei Andrew Fan wrote:
>> This change refactors the RSAPadding class to return an output record
>> containing the status instead of relying on exception object to indicate a
>> failure.
>>
>> Thanks in advance for review~
>> Valerie
>
> src/java.base/share/
On Tue, 11 Jul 2023 23:19:40 GMT, Valerie Peng wrote:
> This change refactors the RSAPadding class to return an output record
> containing the status instead of relying on exception object to indicate a
> failure.
>
> Thanks in advance for review~
> Valerie
Changes requested by xuelei (Review
On Mon, 27 Mar 2023 08:44:31 GMT, Aleksey Shipilev wrote:
> If the exception creation is the problem, maybe we should turn it stackless
This is one direction of the update, I think. Alternatively, it may be doable
by not using exception in the unpad() implementation any longer.
-
On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin wrote:
> This change will move the instantiation of BadPaddingException into the
> branch of the if statement where it is thrown. This will decrease the
> overhead of calling `unpadV15` and `unpadOAEP`. Please see the associated
> work item for p
On Tue, 14 Mar 2023 21:58:46 GMT, Xue-Lei Andrew Fan wrote:
>> May I get a chance to review it before the integration? I may need more
>> time to dig into time-constant issue.
>
>> May I get a chance to review it before the integration? I may need more time
>> to dig into time-constant issue.
On Tue, 14 Mar 2023 21:58:46 GMT, Xue-Lei Andrew Fan wrote:
>> May I get a chance to review it before the integration? I may need more
>> time to dig into time-constant issue.
>
>> May I get a chance to review it before the integration? I may need more time
>> to dig into time-constant issue.
On Wed, 15 Mar 2023 18:08:20 GMT, Cesar Soares Lucas
wrote:
> I may be wrong here but my take on this is that there is nothing at the
> language level that prevents the compiler from optimizing the code and moving
> the allocation inside the "If". In fact, GRAAL might as well be doing this as
On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin wrote:
> This change will move the instantiation of BadPaddingException into the
> branch of the if statement where it is thrown. This will decrease the
> overhead of calling `unpadV15` and `unpadOAEP`. Please see the associated
> work item for p
On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin wrote:
> This change will move the instantiation of BadPaddingException into the
> branch of the if statement where it is thrown. This will decrease the
> overhead of calling `unpadV15` and `unpadOAEP`. Please see the associated
> work item for p
On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin wrote:
> This change will move the instantiation of BadPaddingException into the
> branch of the if statement where it is thrown. This will decrease the
> overhead of calling `unpadV15` and `unpadOAEP`. Please see the associated
> work item for p
On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin wrote:
> This change will move the instantiation of BadPaddingException into the
> branch of the if statement where it is thrown. This will decrease the
> overhead of calling `unpadV15` and `unpadOAEP`. Please see the associated
> work item for p
On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin wrote:
> This change will move the instantiation of BadPaddingException into the
> branch of the if statement where it is thrown. This will decrease the
> overhead of calling `unpadV15` and `unpadOAEP`. Please see the associated
> work item for p
On Tue, 14 Mar 2023 21:23:02 GMT, Xue-Lei Andrew Fan wrote:
> May I get a chance to review it before the integration? I may need more time
> to dig into time-constant issue.
If I read the Bleichenbacher's Attack[1][2] right, the attack works if it can
tell the difference between good condition
On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin wrote:
> This change will move the instantiation of BadPaddingException into the
> branch of the if statement where it is thrown. This will decrease the
> overhead of calling `unpadV15` and `unpadOAEP`. Please see the associated
> work item for p
On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin wrote:
> This change will move the instantiation of BadPaddingException into the
> branch of the if statement where it is thrown. This will decrease the
> overhead of calling `unpadV15` and `unpadOAEP`. Please see the associated
> work item for p
On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin wrote:
> This change will move the instantiation of BadPaddingException into the
> branch of the if statement where it is thrown. This will decrease the
> overhead of calling `unpadV15` and `unpadOAEP`. Please see the associated
> work item for p
On Sat, 25 Feb 2023 02:38:47 GMT, David Schlosnagle wrote:
>> This change will move the instantiation of BadPaddingException into the
>> branch of the if statement where it is thrown. This will decrease the
>> overhead of calling `unpadV15` and `unpadOAEP`. Please see the associated
>> work i
On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin wrote:
> This change will move the instantiation of BadPaddingException into the
> branch of the if statement where it is thrown. This will decrease the
> overhead of calling `unpadV15` and `unpadOAEP`. Please see the associated
> work item for p
On Thu, 23 Feb 2023 21:52:14 GMT, Ahmed Muhsin wrote:
> There is one failure in the pre-submit tests which I believe is unrelated to
> this change:
The same test is failing in at least one other PR:
https://github.com/openjdk/jdk/pull/12735/checks?check_run_id=11564672673
-
PR: h
On Thu, 23 Feb 2023 18:15:35 GMT, Ahmed Muhsin wrote:
> This change will move the instantiation of BadPaddingException into the
> branch of the if statement where it is thrown. This will decrease the
> overhead of calling `unpadV15` and `unpadOAEP`. Please see the associated
> work item for p
47 matches
Mail list logo
