I'm not sure what the problem is. If X is uniform, then "the number of
leading zero bits" of X is exponential. The probability of getting a
"small" number, in which the first (say) 32 bits are 0 is 2^-32. If this
is what is measured by the histrogram[5], then the current
implementation looks
+core-libs-dev for additional API expertise.
On 7/25/2018 10:29 AM, Adam Petcher wrote:
The draft CSR[1] for the EdDSA API[2] is ready for review. Please take
a look and send me any feedback you may have. Here are a few
high-level notes to explain the API:
1) Where possible, this API
Latest webrev: http://cr.openjdk.java.net/~apetcher/8181594/webrev.02/
Comments inline below.
In addition, I also changed the name of IntegerModuloP_Base to
IntegerModuloP, and IntegerModuloP to ImmutableIntegerModuloP.
On 3/11/2018 12:04 PM, Xuelei Fan wrote:
On 2/26/2018 10:39 AM, Adam
review the rest when I understand more about the interfaces design.
Thanks,
Xuelei
On 1/30/2018 8:52 AM, Adam Petcher wrote:
+core-libs-dev
On 1/26/2018 4:06 PM, Adam Petcher wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8181594
Webrev: http://cr.openjdk.java.net/~apetcher/8181594/web
+core-libs-dev
On 1/26/2018 4:06 PM, Adam Petcher wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8181594
Webrev: http://cr.openjdk.java.net/~apetcher/8181594/webrev.00/
This is a code review for the field arithmetic that will be used in
implementations of X25519/X448 key agreement
The spec of the new method doesn't give me enough information to
determine whether it is safe to call it when the value of the length
argument is much larger than the number of bytes I expect to actually
read. This use case comes up frequently in security libraries, because
we have to handle
+core-libs-dev (to get some additional API guidance)
On 1/3/2018 11:26 AM, Adam Petcher wrote:
Now that the JEP[1] for X25519/X448 key agreement is a candidate, we
can proceed with the API and specification review. Please review the
proposed API spec[2] and provide comments by the end
