On 7/26/2018 5:05 PM, Michael StJohns wrote:
The test vectors will not pass, because they are calling the byte
array from which the private key and the signing value are derived as
the private key.
However, each and every signature generated by the above approach
(e.g. using a *real* private
On 7/26/2018 4:24 PM, Adam Petcher wrote:
On 7/26/2018 3:58 PM, Michael StJohns wrote:
On 7/25/2018 2:05 PM, Adam Petcher wrote:
Did you mean PrivateKey ::= OctetToInteger(random)? Setting/clearing
bits here destroys information. If we don't prune here, then we can
reverse this operation la
On 7/26/2018 3:58 PM, Michael StJohns wrote:
On 7/25/2018 2:05 PM, Adam Petcher wrote:
Did you mean PrivateKey ::= OctetToInteger(random)? Setting/clearing
bits here destroys information. If we don't prune here, then we can
reverse this operation later to get the byte array back to give to
On 7/25/2018 2:05 PM, Adam Petcher wrote:
On 7/25/2018 11:24 AM, Michael StJohns wrote:
*sigh* Private keys are big integers. There's an associated
parameter used in signing that the implementation described in the
RFC (*not a standard please note*) generates from a common random
byte arra
On 7/25/2018 11:24 AM, Michael StJohns wrote:
*sigh* Private keys are big integers. There's an associated parameter
used in signing that the implementation described in the RFC (*not a
standard please note*) generates from a common random byte array -
that byte array is NOT a (or the) priva
On 7/25/2018 10:29 AM, Adam Petcher wrote:
2) Similar to X25519/X448, private keys are byte arrays, and public
keys coordinates. Though we can't get by with a single BigInteger
coordinate for EdDSA, so I am using the new EdPoint class to hold the
coordinates.
*sigh* Private keys are big integ
+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 is simi
