I wrote an AttributeConverter to map an EdDSAPublicKey to/from bytes, but when testing it, I found

org.springframework.orm.jpa.JpaSystemException: could not serialize; nested exception is org.hibernate.type.SerializationException: could not serialize
Caused by: java.io.NotSerializableException: net.i2p.crypto.eddsa.math.ed25519.Ed25519LittleEndianEncoding

This can easily be fixed by making Encoding serializable. Ed25519ScalarOps must also be serializable for the Hibernate converter to work, and it may be sensible to have BigIntegerScalarOps serializable as well.

Currently EdDSAPrivateKey and EdDSAPublicKey have no getEncoded() implementation thus leading to a situation where keys cannot be serialized and loaded without some external serialization facility.

This may be possible by following draft proposals for using new curves in RFC5280 which indicates RFC 3279 section 2.3.5 should be followed for these key types.

I'm getting

No installed provider supports this key: net.i2p.crypto.eddsa.EdDSAPrivateKey

when trying to sign a byte[]. I've implemented Security.addProvider(new EdDSASecurityProvider());

What's wrong?

I have tried to use the library with the BigInteger* objects and it seams not working.

I have changed the EdDSANamedCurveTable to

    private static final Field ed25519field = new Field(
                    256, // b
                    Utils.hexToBytes("edffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff7f"), // q
                    new BigIntegerLittleEndianEncoding());

    private static final Curve ed25519curve = new Curve(ed25519field,
            Utils.hexToBytes("a3785913ca4deb75abd841414d0a700098e879777940c78c73fe6f2bee6c0352"), // d
            ed25519field.fromByteArray(Utils.hexToBytes("b0a00e4a271beec478e42fad0618432fa7d7fb3d99004d2b0bdfc14f8024832b"))); // I

    private static final EdDSANamedCurveSpec ed25519sha512 = new EdDSANamedCurveSpec(
            CURVE_ED25519_SHA512,
            ed25519curve,
            "SHA-512", // H
            new BigIntegerScalarOps(ed25519field,new BigInteger("5")), // l
            ed25519curve.createPoint( // B
                    Utils.hexToBytes("5866666666666666666666666666666666666666666666666666666666666666"),
                    true)); // Precompute tables for B

When i try to sign and verify data withe the generated key pair, i get false as return value from verify method.

KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance(EdDSAKey.KEY_ALGORITHM,
				SecunetEdDSASecurityProvider.PROVIDER_NAME);
		KeyPair keyPair = keyPairGenerator.generateKeyPair();
		Signature s = Signature.getInstance(EdDSAEngine.SIGNATURE_ALGORITHM);
		s.initSign(keyPair.getPrivate());
		s.update("hello".getBytes());
		byte[] signedBytes = s.sign();
		
		s.initVerify(keyPair.getPublic());
		s.update("hello".getBytes());
		
		Assert.assertTrue(s.verify(signedBytes));

Is it a bug or is it my mistake.

Thanks & best regards
Jens

Hello!

I am having problems using the library in an OSGi application. The fix for the dependency problem I have, regarding sun.security.x509 is already here. Would it be possible for you to create a new release? Otherwise I (and probably others as well) am forced to create a private fork and use a locally built release.

Thanks a lot!
Sebastian

A simple computation as:

final FieldElement nodeSecret = Utils.getRandomFieldElement();
final GroupElement nodeKey = Utils.basePoint.scalarMultiply(nodeSecret.toByteArray());
    
final FieldElement termSecret = Utils.getRandomFieldElement();
final GroupElement termKey = Utils.basePoint.scalarMultiply(termSecret.toByteArray());
    
nodeKey.scalarMultiply(termSecret.toByteArray());

Fails with:

Exception in thread "main" java.lang.NullPointerException
at net.i2p.crypto.eddsa.math.GroupElement.select(GroupElement.java:930)
at net.i2p.crypto.eddsa.math.GroupElement.scalarMultiply(GroupElement.java:964)
at AOTMainTest.main(AOTMainTest.java:26)

During an investigation of the security of EdDSA, published in:
https://eprint.iacr.org/2020/1244

We have found a malleability issue in ed25519-java, specifically in v. 0.3.0.

The issue, detailed in the paper, is the well-known EdDSA malleability issue of checking that s is in the range [0, L), where L is the order of the larger group.

ed25519-java does not perform a check on the scalar to avoid signature malleability, whether through bit-checking or as a full arithmetic check.

The absence of this check is against specifications (RFC 8032, FIPS 196-5 draft) and costs the library the SUF-CMA property. The lack of this property means that the adversary can construct alternative signatures for a given signed message that will pass ed25519-java verification.

Here are the (hex-encoded) test vectors we used (the specific claim discussed in the issue is that ed25519-java passes vector #6, which has message finishing in ..ec40 and a signature finishing in ..a514, and vector #7, which has a message ending in ...ec40 and a signature finishing in ..8c22):
https://github.com/novifinancial/ed25519-speccheck/blob/master/cases.json

The vectors were generated using the source you'll find at:
https://github.com/novifinancial/ed25519-speccheck/blob/master/src/main.rs

Here is the way we ran this vector and the others of our set against ed25519-java:
https://github.com/novifinancial/ed25519-speccheck/tree/master/scripts/ed25519-java

This is joint work with @kchalkias @valerini

Is it possible to get a new release sometime soon (once master is passing tests etc)? The last (and only) release was almost a year ago. Thanks!

Environment:

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T18:41:47+02:00)
Maven home: C:\Program Files\Java\apache-maven-3.3.9
Java version: 1.8.0_121, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_121\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"

Error

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 42.502 s
[INFO] Finished at: 2017-03-21T05:59:33+02:00
[INFO] Final Memory: 26M/131M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.9.1:jar (attach-javadocs) on project eddsa: MavenReportException: Error while creating archive:
[ERROR] Exit code: 1 - javadoc: error - Argument for -header contains JavaScript.
[ERROR] Use --allow-script-in-comments to allow use of JavaScript.
[ERROR]
[ERROR] Command line was: "C:\Program Files\Java\jdk1.8.0_121\jre\..\bin\javadoc.exe" @options @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in 'D:\Projects\apache\str4d\ed25519-java\target\apidocs' dir.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

This software is licensed as Public Domain according to the CC0-1.0 License. This license does not grant any patent or trademark rights, or rather, it explicitly excludes such rights from the dedication to the public domain.

We would like to use a part of this software which is included in the MariaDB connector and would like to make sure that there is no IP attached which would jeopardize our project. Can you confirm this?

ie. EdDSA where the input message is H(m).

See https://tools.ietf.org/html/rfc8032 and http://ed25519.cr.yp.to/eddsa-20150704.pdf

RFC 8410 section 7 specifies that a private key may contain attributes, or its corresponding public key. These are marked as OPTIONAL, which per BCP 14 means that we

MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality.

I interpret this as meaning we need to handle their potential presence when decoding a key:

• If attributes are present, we skip over them.
• If a public key is present, we verify that it matches the private key.

I don't interpret this as meaning we need to support storing them (if provided), or that getEncoded() MUST return the same encoding as was originally passed in (in fact, it explicitly disclaims this in order to migrate keys encoded using the older draft specification back from when this library was first written). In other words, getEncoded() would return the canonical minimal encoding as already-implemented.

See

Most likely I am missing something obvious, not having a lot of experience with cryptographic APIs - apologizes if that is the case.

I am trying to general a pub/priv pair of keys and I would like to export those to a file so I can re-use them next time my application start.
How can it be done here? Should I export the seed of the private key and recreate the object later?
Are there factory methods/classes somewhere that allow such operation?

If someone could provide a sample code, that would be the best. Thanks!

Hi!
When i use the ed25519-java/blob/master/test/net/i2p/crypto/eddsa/math/MathUtils.java , i think i find a BUG .
Biginteger t = 45891519889189295806511069281801979123367323329425028068599993329491679735154
Biginteger s = 12004524729468801905274423222541974803267669003395253951128798674464885084797
i need compute [s]G + [t]G, G is a random point use MathUtils.getRrandompoint（），obviously,
(s + t)mod(MathUtils.getQ()) == 2, so, [s]G+[t]G = [2]G, but the reslut is wrong ,it not equal.
/* (P3 = t*G + s*G) != P4 = ((s+t)modQ)*G */ GroupElement G = MathUtils.getRandomGroupElement(); BigInteger t = new BigInteger("45891519889189295806511069281801979123367323329425028068599993329491679735154"); BigInteger s = new BigInteger("12004524729468801905274423222541974803267669003395253951128798674464885084797"); GroupElement P1 = MathUtils.scalarMultiplyGroupElement(G,MathUtils.toFieldElement(t)); GroupElement P2 = MathUtils.scalarMultiplyGroupElement(G,MathUtils.toFieldElement(s)); GroupElement P3 = MathUtils.addGroupElements(P1,P2); BigInteger x = (t.add(s)).mod(MathUtils.getQ()); GroupElement P4 = MathUtils.scalarMultiplyGroupElement(G,MathUtils.toFieldElement(x)); System.out.println(P4.equals(P3)); System.out.println(x);

Any reason this isn't published?

Hello, could you please add the release tag for the 0.2.0 release?

Hi! I recently looked into testing the compatibility between Yubico/java-webauthn-server and ed25519-java, and I quickly ran into a small issue: the JCA provider algorithm names differ from those used in OpenJDK 15. Specifically, OpenJDK does not include the hash algorithm in Signature names, while ed25519-java does. See: Java Security Standard Algorithm Names (Java SE 15)

I found that a similar topic was discussed in issue #33, but it seems like the JCA standard decided to not continue the same naming pattern - presumably because, as noted in #33, EdDSA instantiations already include a choice of a particular hash algorithm.

Anyway, it might be worth considering to align with the standard JCA names to improve interoperability.

v3.8.0 defines an automatic module name

$ jarviz module name --file eddsa-0.3.0.jar
subject: eddsa-0.3.0.jar
name: net.i2p.crypto.eddsa
source: manifest
automatic: true
valid: true

$ jarviz module descriptor --file eddsa-0.3.0.jar
subject: eddsa-0.3.0.jar
name: net.i2p.crypto.eddsa
version: 0.3.0
open: false
automatic: true
requires:
  java.base mandated
contains:
  net.i2p.crypto.eddsa
  net.i2p.crypto.eddsa.math
  net.i2p.crypto.eddsa.math.bigint
  net.i2p.crypto.eddsa.math.ed25519
  net.i2p.crypto.eddsa.spec

$ jarviz bytecode show --file eddsa-0.3.0.jar
subject: eddsa-0.3.0.jar
Unversioned classes. Bytecode version: 50 (Java 6) total: 33

I'd be great if the library supplied a full Java module descriptor. It's possible to keep bytecode baseline compatible with Java 6 while providing a full module descriptor thanks to ModiTect. This will help modular projects that consume eddsa, specifically those that create custom Java Runtimes with jlink, as the latter does not support automatic modules but explicit modules. If interested I can send a PR to make it happen.

I am attempting to import the following as a PKCS8 and am getting an incorrect length exception

30 35
02 01 00
30 05
06 03 2a 65 70
04 29
30 27 02 01 01 04 22 04 20 9d 61 b1 9d ef fd 5a
60 ba 84 4a f4 92 ec 2c c4 44 49 c5 69 7b 32 69
19 70 3b ac 03 1c ae 7f 60

I was using this library: https://github.com/k3d3/ed25519-java but its using BitIntegers and was very slow. I want to use a Blake2b hash with ED25519 to sign some keys, and I was wondering how I can do this? I'm thinking I make a Blake2b MessageDigest class and then define an EdDsaNamedCurve spec using this hash, correct? Sorry, I could not find any example code doing this.

This is a blocker for the 0.2 release which includes a Provider, meaning that the names become part of the API.

I'm using this library to do some non-standard cryptographic functions, and I need the scalarMultiplication. Now I wonder why the following line is commented out, as it would work with this line, but without I have to call .precompute(true) in my code.

When using EdDSASecurityProvider I get unexpected errors when running my tests. The first test run always succeeds but subsequent runs always fail with strange errors like:

cannot identify EdDSA public key: class net.i2p.crypto.eddsa.EdDSAPublicKey

A asked about a more detailed example on stackoverflow.

I am using other jce providers and this only seems to happen with EdDSASecurityProvider. Is there something specific that this provider is doing that might cause this?

Thanks

I see that the original library offers batch verification:

const unsigned char *mp[num] = {message1, message2..}
size_t ml[num] = {message_len1, message_len2..}
const unsigned char *pkp[num] = {pk1, pk2..}
const unsigned char *sigp[num] = {signature1, signature2..}
int valid[num]

/* valid[i] will be set to 1 if the individual signature was valid, 0 otherwise */
int all_valid = ed25519_sign_open_batch(mp, ml, pkp, sigp, num, valid) == 0;

Was it integrated in the Java library?

Is this library implemented to be resistant to side-channel attacks such as TLBleed?

Is there any working proguard configuration for this library? Other than

-keepnames class net.i2p.crypto.eddsa.**

I see that in EdDSASecurityProvider there is some classes mentioned by fully qualified name. Do we need to just have -keepnames for this three? Or some other configuration also required?

Lots of classes implementing Serializable. Is this optional feature? I mean if my code does not use serialization it is safe to not care about preserving this classes?

Is there any other cases I should be aware which can cause problems with proguard?

Once we will have good understanding of what proguard config for this library should be, can you include it to the source code of this library? This is currently the best practice for java libraries which can be used on Android.

See https://tools.ietf.org/html/rfc8032#section-5.2

There is already a pom.xml, but it appears no Maven repo releases have been made. Other projects have started copying the source directly into their projects thereby creating a situation where any security problems will persist for a long time since each copy will have to be tracked down and updated.

If this is not the authoritative repository for this code anymore, please point to it in the README.md.

The current Ed25519 OID and EdDSAPublicKey encoding format were taken from https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04 which is now expired. The EdDSAPrivateKey was never specified in that draft, and was based on PKCS#8.

There is now a new draft from the curdle WG that specifies different OIDs and encodings. We should rename the existing methods (to indicate their deprecation while provide a migration pathway for library users), and add new encoding and decoding methods corresponding to the current draft.

Tor is implementing various additions to Ed25519 ref10 to support extended use cases. Similar extensions here would benefit I2P, as well as Java implementations of Tor.

To add:

• Key blinding
• Conversion of Curve 25519 keys to Ed25519

See Tor ticket 12980 and links therein.

Most of the tests in Ed25519FieldElementTest are actually applicable to any FieldElement. They should be factored out into an abstract parent test, so they can be applied to both Ed25519FieldElement and BigIntegerFieldElement.

Returning no such algorithm rather than InvalidKeySpec exception for unknown OIDs makes it easier to diagnose and implement work arounds for the problem in code.

This is a minor nit request, but would it be possible for EdDSANamedCurveTable to clarify its contract for accessing the ED_25519 curve spec (and other curves when implemented)?

One option would be to simply publish a static final String constant somewhere that defines the "name" of supported curves. That would at least allow the library to specify the String to pass-in to getByName. As it stands for ed25519, I keep having to define this in various projects that use this lib, which is somewhat error-prone. Additionally, this contract seems to have changed between 0.1.0 and 0.2.0 (which is fine - the version changed, but it's currently a bit awkward/error-prone to access the curve).

For example, the following would be trivial to add to EdDSANamedCurveTable:

public class EdDSANamedCurveTable {
   public static final String ED_25519 = "Ed25519";
       ... // rest of this class...
}

That would allow me to just do this:

final EdDSANamedCurveSpec edParams = EdDSANamedCurveTable.getByName(ED_25519);

However, a more preferable mechanism would be to make EdDSANamedCurveTable aware of some of its curves. For example, perhaps there should be a helper method like this in EdDSANamedCurveTable:

public static EdDSANamedCurveSpec ed25519() {
    return curves.get(ED_25519);
}

Hi
The following source files are without license headers:
./src/net/i2p/crypto/eddsa/EdDSAEngine.java
./src/net/i2p/crypto/eddsa/EdDSAKey.java
./src/net/i2p/crypto/eddsa/EdDSAPrivateKey.java
./src/net/i2p/crypto/eddsa/EdDSAPublicKey.java
./src/net/i2p/crypto/eddsa/KeyFactory.java
./src/net/i2p/crypto/eddsa/KeyPairGenerator.java
./src/net/i2p/crypto/eddsa/Utils.java
./src/net/i2p/crypto/eddsa/math/Constants.java
./src/net/i2p/crypto/eddsa/math/Curve.java
./src/net/i2p/crypto/eddsa/math/Encoding.java
./src/net/i2p/crypto/eddsa/math/Field.java
./src/net/i2p/crypto/eddsa/math/FieldElement.java
./src/net/i2p/crypto/eddsa/math/GroupElement.java
./src/net/i2p/crypto/eddsa/math/ScalarOps.java
./src/net/i2p/crypto/eddsa/math/bigint/BigIntegerFieldElement.java
./src/net/i2p/crypto/eddsa/math/bigint/BigIntegerLittleEndianEncoding.java
./src/net/i2p/crypto/eddsa/math/bigint/BigIntegerScalarOps.java
./src/net/i2p/crypto/eddsa/math/ed25519/Ed25519FieldElement.java
./src/net/i2p/crypto/eddsa/math/ed25519/Ed25519LittleEndianEncoding.java
./src/net/i2p/crypto/eddsa/math/ed25519/Ed25519ScalarOps.java
./src/net/i2p/crypto/eddsa/spec/EdDSAGenParameterSpec.java
./src/net/i2p/crypto/eddsa/spec/EdDSANamedCurveSpec.java
./src/net/i2p/crypto/eddsa/spec/EdDSANamedCurveTable.java
./src/net/i2p/crypto/eddsa/spec/EdDSAParameterSpec.java
./src/net/i2p/crypto/eddsa/spec/EdDSAPrivateKeySpec.java
./src/net/i2p/crypto/eddsa/spec/EdDSAPublicKeySpec.java

./test/net/i2p/crypto/eddsa/Ed25519TestVectors.java
./test/net/i2p/crypto/eddsa/EdDSAEngineTest.java
./test/net/i2p/crypto/eddsa/UtilsTest.java
./test/net/i2p/crypto/eddsa/math/ConstantsTest.java
./test/net/i2p/crypto/eddsa/math/GroupElementTest.java
./test/net/i2p/crypto/eddsa/math/MathUtils.java
./test/net/i2p/crypto/eddsa/math/PrecomputationTestVectors.java
./test/net/i2p/crypto/eddsa/math/bigint/BigIntegerScalarOpsTest.java
./test/net/i2p/crypto/eddsa/math/ed25519/Ed25519FieldElementTest.java
./test/net/i2p/crypto/eddsa/math/ed25519/Ed25519LittleEndianEncodingTest.java
./test/net/i2p/crypto/eddsa/math/ed25519/Ed25519ScalarOpsTest.java
./test/net/i2p/crypto/eddsa/spec/EdDSAPrivateKeySpecTest.java

Please, add license headers
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#License_Clarification
Thanks in advance
Regards

Hi, thanks for the library, a great implementation of Ed25519.

I'm try to find a way to convert Ed25519 public key(or private key) to Curve25519, like libsodium here.

https://github.com/jedisct1/libsodium/blob/927dfe8e2eaa86160d3ba12a7e3258fbc322909c/src/libsodium/crypto_sign/ed25519/ref10/keypair.c#L46-L83

The API of 2 library has lots of differences, could you please give some suggestions about this?

https://github.com/str4d/ed25519-java/blob/master/src/net/i2p/crypto/eddsa/Utils.java#L81

On inputs of odd-length n, this for-loop tries to access the char at index, an error.

The setField method of the super class is synchronized, but this method isn’t.

See #19 (comment)

How encode EdDSAPublicKey / EdDSAPrivateKey for later usage in OpenSSH?

Acording to draft-bjh21-ssh-ed25519-00 & draft-josefsson-eddsa-ed25519-03. I am trying to extract the values for encoding... but i don't known where to get these.

This recent paper demonstrates using a differential power analysis attack on the SHA-512 part of the Ed25519 signature generation to recover the nonce key (aka auxiliary key), and also proposes a mitigation: https://eprint.iacr.org/2017/985.pdf

We need to create a scenario such that an attacker is not able
make a hypothesis on the constant key value. This can be achieved by padding
the key with fresh random bits such that the first 1024-bit block is composed
only by key and random value, without any bits known to the attacker. The
input message will be processed in blocks after that. Fig. 9 visualizes how the
input should look. The R0 block would be a random number of 768 bits. We
argue that is also possible to have an R0 block composed by 128 bits of randomness
and pad the rest of the block with 640 bits with a constant value (e.g. all
zero).
[...]
Obviously, this countermeasure kills the deterministic signature properties,
but we do not see this as a dramatic problem. The main motivation for the proposal
of deterministic signature was to avoid a poor management of randomness
that can introduce security problems [12, 14]. The proposed countermeasure is
also not re-introducing the strong security requirement of randomness needed
by ECDSA. Basically, even if the same randomness is used to sign two different
messages, the attacker will not be able to recover the key as would it be possible
with ECDSA. Additionally we want to highlight that the signature verification
procedure remains as is.

As I'm using Ed25519 in an IoT-type device where this type of attack is (at least theoretically) possible, I'm considering adding (optional) support for this mitigation. Would there be interest in this if I provide a PR?

It should be straightforward to add this logic to EdDSAEngine.digestInitSign, conditional on a (new) randomize flag added to EdDSAParameterSpec, which could then be exposed as an EdDSANamedCurveSpec with a different identifier, e.g. Ed25519rnd.

code:

import java.io.BufferedReader;
import java.io.FileReader;
import java.nio.charset.StandardCharsets;
import java.security.MessageDigest;
import java.security.PrivateKey;
import java.security.Signature;
import java.util.Base64;

import net.i2p.crypto.eddsa.Utils;
import net.i2p.crypto.eddsa.EdDSAEngine;
import net.i2p.crypto.eddsa.EdDSAPrivateKey;
import net.i2p.crypto.eddsa.spec.EdDSANamedCurveTable;
import net.i2p.crypto.eddsa.spec.EdDSAParameterSpec;
import net.i2p.crypto.eddsa.spec.EdDSAPrivateKeySpec;

public class EdSignTest {
	// ed25519
	final static EdDSAParameterSpec spec = EdDSANamedCurveTable.getByName(EdDSANamedCurveTable.ED_25519);

	public static void main(String[] args) throws Exception {
        byte[] ZERO_H = Utils.hexToBytes("39e6fb57062449a6a058f7117b3a3ac7e92fd23a6679bc23c882efe2cfb9b520d79a86ac2ebfe10add5e26bead8f6528e8d3b28785b2fe112fe3b78bac27787d");

		String data = "lexar{\"status\": true}BWTbpxar9GPX6yl7H6C5bClxaBFhdxgd1622015270";
		
		//Signature signature = new EdDSAEngine(MessageDigest.getInstance(spec.getHashAlgorithm()));
		EdDSAEngine signature = new EdDSAEngine(MessageDigest.getInstance(spec.getHashAlgorithm()));
		EdDSAPrivateKeySpec privKey = new EdDSAPrivateKeySpec(spec, ZERO_H); //new EdDSAPrivateKeySpec(privSeed, spec);
		PrivateKey sKey = new EdDSAPrivateKey(privKey);
		
		signature.initSign(sKey);
		byte[] msg = data.getBytes(StandardCharsets.UTF_8);
		System.out.println("msg.len:"+ msg.length);
		signature.update(msg);
		byte[] s = signature.sign();
		System.out.println("DATA_HEX : " + Utils.bytesToHex(s));
		String encodedString = Base64.getUrlEncoder().encodeToString(s);

		System.out.println("DATA : " + data);
		System.out.println("SIGN : " + encodedString);
	}
}

Currently the Curve25519-specific arithmetic is closely-coupled to its use in this EdDSA implementation. Part of the reason for this was to make it theoretically easier to generically support other EdDSA instantiations in the library, such as Ed448. However, the close coupling makes it difficult to reuse the Curve25519 arithmetic for either X25519 operations, or as an internal representation for ristretto255.

Meanwhile, since this library was created, the wider community has standardised Ed25519 and Ed448 in RFC 8032. In particular, section 3 states:

   The generic EdDSA digital signature system with its 11 input
   parameters is not intended to be implemented directly.  Choosing
   parameters is critical for secure and efficient operation.  Instead,
   you would implement a particular parameter choice for EdDSA (such as
   Ed25519 or Ed448), sometimes slightly generalized to achieve code
   reuse to cover Ed25519 and Ed448.

Therefore, in the next version of this library I plan to move the Curve25519 arithmetic out of this library, and remove the BigInteger-based arithmetic.

This is a breaking change, because the current API of this library exposes arithmetic classes that will be moved (such as GroupElement).

My strategy for this will be:

1. Create a new library, instantiated with the Curve25519 group and field arithmetic from this library.
2. Refactor the arithmetic code within the new library as necessary to create a standalone API there.
3. Publish the new library.
4. Replace the Curve25519 arithmetic in this library with the new library, refactoring the API here as necessary.

This library will then solely be focused on implementing the EdDSA algorithm, the JCA engine, and the higher-level encoding formats such as X.509.

FIDO UAF 1.1 specification (https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-registry-v2.0-rd-20180702.html) recommends the EdDSA keys to be encoded as per COSE specification as defined in Section 7 of https://tools.ietf.org/html/rfc8152#section-7 . Can someone guide on how to achieve this. Essentially, the getEncoded() on the EdDSAPublicKey object should return the keys in COSE format, and similarly one should be able to construct EdDSAPublicKey object from key bytes [] defined in COSE. Any help is highly appreciated.

We occasionally see this crash in the field (haven't managed to reproduce):

#0. Crashed: main
       at net.i2p.crypto.eddsa.spec.EdDSANamedCurveTable.getByName(EdDSANamedCurveTable.java:67)
       at org.stellar.sdk.KeyPair.(KeyPair.java:29)
       at org.stellar.sdk.KeyPair.fromAccountId(KeyPair.java:104)
[...]

Fatal Exception: java.lang.ExceptionInInitializerError
       at net.i2p.crypto.eddsa.spec.EdDSANamedCurveTable.getByName(EdDSANamedCurveTable.java:67)
       at org.stellar.sdk.KeyPair.(KeyPair.java:29)
       at org.stellar.sdk.KeyPair.fromAccountId(KeyPair.java:104)
[...]

Caused by java.lang.NullPointerException: Attempt to invoke virtual method 'b.a.a.a.a.e b.a.a.a.a.e.g()' on a null object reference
       at net.i2p.crypto.eddsa.math.ed25519.Ed25519FieldElement.invert(Ed25519FieldElement.java:811)
       at net.i2p.crypto.eddsa.math.GroupElement.precompute(GroupElement.java:472)
       at net.i2p.crypto.eddsa.math.Curve.createPoint(Curve.java:78)
       at net.i2p.crypto.eddsa.spec.EdDSANamedCurveTable.(EdDSANamedCurveTable.java:43)
       at net.i2p.crypto.eddsa.spec.EdDSANamedCurveTable.getByName(EdDSANamedCurveTable.java:67)
       at org.stellar.sdk.KeyPair.(KeyPair.java:29)
       at org.stellar.sdk.KeyPair.fromAccountId(KeyPair.java:104)
[...]

I currently use this library directly from this project importing it via maven with:

<dependency>
   <groupId>net.i2p.crypto</groupId>
   <artifactId>eddsa</artifactId>
   <version>0.3.0</version>
</dependency>

From other issues here, it feels, that the development focus more on the "copy/origin" in the i2p project.

So, are there plans to update this project as well?

Currently CC0 license is not approved from the Open Source Initiative (OSI) and although CC0 is not a "strange" license at all it has some problems in certain jurisdictions especial in europe (e.g. Germany).
My company (residing in Germany) want's to use that greate library but our legal department raised the concern that this is not possible in Germany without risk. So I am wondering if it would be possible to change the license of this library or do some double licensing with any of the widespread OSI licensed (Apache, BSD, MIT, ...).

Different implementations apparently use different ways to import/export a binary representation of the private key[1]. Some do not keep the seed value for example.

I think an additional constructor or a static factory method for EdDSAPrivateKeySpec to derive a/A from h without the seed may be useful. I have cobbled on together for my own needs in 9d5b353 but a more rigorous implementation is probably needed for it to be included officially in the library.

[1] https://blog.mozilla.org/warner/2011/11/29/ed25519-keys/

Triggered by lightsail-network/java-stellar-sdk#131

Replicate with the following:

byte[] key = {15, -29, -22, -17, 22, 101, -81, -39, -118, 124, -14, -105, -52, 109, -6, 88, 17, 12, -13, 93, 59, 104, 63, -13, -94, 52, -24, -125, 76, -23, 113, -47};
new EdDSAPublicKeySpec(key, EdDSANamedCurveTable.getByName("ed25519"));

In v0.3.0, results in:

Exception in thread "main" java.lang.IllegalArgumentException: not a valid GroupElement
	at net.i2p.crypto.eddsa.math.GroupElement.<init>(GroupElement.java:336)
	at net.i2p.crypto.eddsa.math.GroupElement.<init>(GroupElement.java:287)
	at net.i2p.crypto.eddsa.spec.EdDSAPublicKeySpec.<init>(EdDSAPublicKeySpec.java:36)

What's happening here?

Not available LICENSE file in source directory structure
Please. Added license and copyright notice.
the fedora pakaging guideline is very strictly precise about this problem
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/LicensingGuidelines#License_Text
thanks
regards