> On Sep 6, 2018, at 5:02 PM, Jamil Nimeh wrote:
>
> Hi Xuelei, thank you for the comments - my replies are in-line:
>
>> On 9/6/2018 2:31 PM, Xuelei Fan wrote:
>> SSLCipher.java
>> --
>> line 2159-2164 in the update vs line 1992-1997 in the old file.
>>
>> The new code is fine, b
Hi Xuelei, thank you for the comments - my replies are in-line:
On 9/6/2018 2:31 PM, Xuelei Fan wrote:
SSLCipher.java
--
line 2159-2164 in the update vs line 1992-1997 in the old file.
The new code is fine, but it takes me a while to analysis the code,
and comparing with the old on
SSLCipher.java
--
line 2159-2164 in the update vs line 1992-1997 in the old file.
The new code is fine, but it takes me a while to analysis the code, and
comparing with the old one. Maybe, we can use the same implementation
code for the same logic for maintenance? Just a very per
I asked the question in a previous email. The key size for x25529 is
fixed, right?
If it is not right, stop here and tell me that it is not right. Keep
reading if it is right.
OK, as the key size for x25519 is fixed, when you know the algorithm is
x25519, you know the key size. Does it so
On 9/6/2018 3:19 PM, Xuelei Fan wrote:
I think I suggested to use NamedParameterSpec, which is a public API.
NamedParameterSpec -> name "x25519"
-> key size is the key size of x25519.
Please let me know if the logic is wrong.
It's that last arrow that I still don't get. How does th
On 9/6/18 12:29 PM, Sean Mullan wrote:
Please review this change to remove code that is no longer necessary
now that pre-JDK 1.2 SecurityManager methods are no longer supported
[1]. In addition, the initialized flag and associated code has been
removed from SecureClassLoader as this was only
Please review this change to remove code that is no longer necessary now
that pre-JDK 1.2 SecurityManager methods are no longer supported [1]. In
addition, the initialized flag and associated code has been removed from
SecureClassLoader as this was only necessary to prevent finalizer
attacks pr
I think I suggested to use NamedParameterSpec, which is a public API.
NamedParameterSpec -> name "x25519"
-> key size is the key size of x25519.
Please let me know if the logic is wrong.
> Also, why do you object to having XECParameters in java.base?
Please read my previous comments.
On 9/6/2018 1:55 PM, Xuelei Fan wrote:
Yes, the key sizes are fixed. All we need in ECUtil is a mapping from
curve name to this (fixed) size. Are you suggesting some other
solution, other than using the XECParameters to map curve names to
key sizes?
Using name only (NamedParameterSpec?) and ha
On 9/6/2018 10:17 AM, Adam Petcher wrote:
In the latest webrev, I changed it so there is a single static
NamedGroupFunctions of each type, and the NamedGroup is passed in as
the first argument to each method that requires it (rather than
being a member of NamedGroupFunctions).
After the r
On 9/6/2018 10:04 AM, Adam Petcher wrote:
On 9/6/2018 12:10 PM, Xuelei Fan wrote:
The algorithm name is not quite sufficient. See the new methods that
were added to ECUtil that encode/decode public keys. We also need to
know the key length (which is in XECParameters) in order to
encode/dec
Minor correction below.
On 9/6/2018 1:04 PM, Adam Petcher wrote:
In the latest webrev, I changed it so there is a single static
NamedGroupFunctions of each type, and the NamedGroup is passed in as
the first argument to each method that requires it (rather than
being a member of NamedGro
On 9/6/2018 12:10 PM, Xuelei Fan wrote:
The algorithm name is not quite sufficient. See the new methods that
were added to ECUtil that encode/decode public keys. We also need to
know the key length (which is in XECParameters) in order to
encode/decode public keys.
I did not get your point.
On 9/5/2018 12:49 PM, Adam Petcher wrote:
New webrev: http://cr.openjdk.java.net/~apetcher/8171279/webrev.02/
On 9/5/2018 1:35 PM, Xuelei Fan wrote:
On 9/5/2018 10:09 AM, Adam Petcher wrote:
Is there some place in the code where JSSE is doing something too
complicated related to these parame
On 9/5/2018 5:53 PM, Michael StJohns wrote:
BigInteger is not required to encode a PKCS8 key, but its trivial to
translate from BigInteger to PKCS8 and vice versa. Note that
internally, the current BigInteger stores the magnitude as an array of
int in big endian order and stores the sign se
15 matches
Mail list logo
