Re: Missing documentation for EdDSA key serialization
Hi Anthony and Mike,
It is not reversing that is the problem but assumption that you know that:
- Reversing is required.
- XOdd should always(?) be set to false.
EdECPoint is presumably targeting other applications which are closer to the
EdDSA core than PKIX and JOSE.
The serialization of EdDSA public keys to RFC 8032 compatible representation is currently
is performed by this "experimentally derived" code:
byte[] rawKey = edEcPoint.getY().toByteArray();
while (rawKey.length < ANTICIPATED_LENGTH) {
prepend rawKey with a zero byte
}
if (edEcPoint.isXOdd()) {
rewKey[0] |= 0x80;
}
rawKey = reverse(rawKey);
This is obviously not something you want to have in a professional solution so
unfortunately the SubjectPublicKeyInfo route seems to be the only credible way
ahead:
https://github.com/cyberphone/openkeystore/blob/427f65df6eb26e9150a1aefd6f0abf3abe761e91/library/src/org/webpki/crypto/CryptoUtil.java#L59
Thanx,
Anders
On 2020-08-31 20:38, Michael StJohns wrote:
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.
Re: Missing documentation for EdDSA key serialization
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.
Re: Missing documentation for EdDSA key serialization
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
Missing documentation for EdDSA key serialization
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
