Missing documentation for EdDSA key serialization

[Michael StJohns]

On 8/31/2020 2:00 PM, Anthony Scarpino wrote:
> On 8/31/20 8:16 AM, Anders Rundgren wrote:
>> On
>> https://tools.ietf.org/html/rfc8032#page-24
>> you can find test vectors that are also used by rfc8037 (JOSE).
>>
>> However, there seems to be no information on how to create an EdDSA 
>> public key from such a vector.
>> Apparently you must be an expert on the inner workings of EdDSA in 
>> order to use this API.
>>
>> I have though managed(...) but 1) it looks strange 2) it may be 
>> incorrect.
>>
>> Steps
>> 1. Convert the hex-code to a byte[] array.
>> 2. Reverse (!) all the bytes in the byte[] array.
>> 3. publicKey = kf.generatePublic(
>>                      new EdECPublicKeySpec(new NamedParameterSpec(alg),
>>                                            new EdECPoint(false, new 
>> BigInteger(1, theByteArray))));
>>
>> Ideally, EdECPoint should have an constructor that does whatever it 
>> takes based on a byte[] array.
>>
>> It is equally fuzzy in the other direction.  A "getByteArray()" on 
>> EdECPoint had been great.
>>
>> Thanx,
>> Anders
>
> Hi,
>
> It does seem like a constructor and/or helper methods would be a good 
> addition.  I filed a bug to track this:
>
> https://bugs.openjdk.java.net/browse/JDK-8252595
>
> thanks
>
> Tony


Generically, maybe this should be added not to the ED based stuff, but 
to BigInteger:

public static BigInteger fromLittleEndianEncoding(int signum, byte[] 
magnitude);

public  byte[] getMagnitude(boolean bigEndian, int sizeInBytes); // if 
size in bytes < actual magnitude size, returns the magnitude bytes, 
otherwise returns the magnitude bytes left or right padded to 
sizeInBytes depending on endianness.

Almost all of the crypto stuff related to converting between the various 
encodings of signatures and keys would benefit from a standard version 
of the left/right padding stuff.

Mike

ps - there's a long thread maybe a year or two ago about internal vs 
external representations of the EDDSA and EDDH keys.  I'm actually kind 
of surprised that the internal representation turned out to be 
BigInteger.   I'm glad it did, but its now kind of strange that we have 
6 extra interface classes when we could probably have gotten away with 
folding them in under the EC* classes.


pps - the alternate way of doing this (and probably the most correct 
way) would be to encode the bytes from the test vector into a 
SubjectPublicKeyInfo public key (see RFC8401)  and run that through the 
key factory.  That should do all the reversing and generating.  You can 
confirm that by doing a getEncoded() on your built public key and 
running it back through the key factory.