It'd be nice if you included ref10 and amd64-64-24k in the benchmarks so it's easier to see if switching to your implementation is worth the effort.

Another interesting variant would be c code (without 128 bit ints) running as a 64 bit executable.

I can't thank you enough for this library! It is unbelievably fast!

I apologize for such a noob request, but please provide an example for how to hash.

The best I can determine, the hash is the last line of the hash section:

void ed25519_hash(uint8_t *hash, const uint8_t *in, size_t inlen);

What should *hash be? Am I correct to assume that *in and inlen are the to be hashed data and its length?

Thank you so very much for this high performance library!

I have crossposted here: http://crypto.stackexchange.com/questions/14676/how-to-hash-with-ed25519-donna

I've finally got the basics working, I think, but for some reason it hangs on ed25519_hash.

Sorry, didn't realize the library hashes before signing. :/

"Use -DED25519_INLINE_ASM to disable the use of custom assembler routines and instead rely on portable C."
should be:
"Use -DED25519_NO_INLINE_ASM to disable the use of custom assembler routines and instead rely on portable C."

floodberry,

Sorry to keep pounding you. Just trying to get my ducks in a row, and as you can see I'm very new to this.

I was just informed of a bug in amd64-64. https://gist.github.com/CodesInChaos/8374632

I tried searching for those lines of code, but neither came up. Can you confirm if this bug is present in your implementation?

Thank you so very much in advance!

Please reply with a base64 encoded public key.

Just my way of saying thank-you.

Hi there,
Recently I am learning about curve25519. After reading the paper, I try to go through the code and I encounter some problems.

Thank you in advance

Considering my other questions, it's pretty easy to see how noob I am.

So here's a noob question: how can the library be properly compiled so that it passes the tests?

Here's my commands:

gcc ed25519.c -m64 -O3 -c
gcc ed25519.o test.c -lssl -lcrypto -m64 -O3
./a.out

This is my output:

60861 ticks/public key generation
64257 ticks/signature
221073 ticks/signature verification
59238 ticks/curve25519 basepoint scalarmult
failed to generate expected result
want: 51,e7,68,e0,f7,a1,88,45,de,a1,cb,d9,37,d4,78,53,1b,95,db,be,66,59,29,3b,94,51,2f,bc,0d,66,ba,3f,
got : 49,b5,f9,d6,81,7e,da,9e,00,c8,83,81,bc,42,dc,75,08,db,e2,e6,63,70,35,1c,a5,35,6d,35,8d,29,51,61,
diff: 18,52,91,36,76,df,52,db,de,69,48,58,8b,96,a4,26,13,4e,39,58,05,29,1c,27,31,64,42,89,80,4f,eb,5e,

This happens no matter what order the compiler arguments are.

test-internals.c reports "success".

Thank you so much for writing this lib!

Sorry! Should've read the directions more closely! :/

On Osx ALIGN is already defined on /usr/include(i386/param.h

define ALIGN(p) __DARWIN_ALIGN(p)

I just renamed it from (ed25519-donna-portable-identify.h) into ALIGN2 and in the followings files :

curve25519-donna-32bit.h
curve25519-donna-helpers.h
curve25519-donna-sse2.h
ed25519-donna-32bit-tables.h
ed25519-donna-basepoint-table.h
ed25519-donna-batchverify.h
ed25519-donna-impl-sse2.h
ed25519-donna-portable.h
ed25519.c
test-internals.c

and it works

for curve25519-donna i just add :

ifdef ALIGN

undef ALIGN

endif

before

/* platform */

if defined(COMPILER_MSVC)

...

in file curve25519-donna-portable.h and its ok.

but for ed25519 its not so simple.

Hi there,
Great work on the library! I want to port the ed25519 and curve25519 implementations of yours to a 32bit MCU with no operating system. Can you give some advice on any considerations that I need to make? Is the code portable to a 32bit MCU without openssl integrated in it?

Best Regards
Srivatsav

It is unclear what this code is licensed under - please clarify.

ed25519-donna.patch.txt

I am using ed25519-donna not for EdDSA, but for general point operations using ed25519 curve.

I noticed that ge25519_double_scalarmult_vartime() does not correctly finalize the result.
If I try to add the result to some other point then I get an incorrect result (not a problem for ed25519.c).
It seems that this is because ge25519_double_scalarmult_vartime() lacks ge25519_p1p1_to_full(r, &t); at the end.

Hi,

I was looking at your code just now but found that it does not name a license? Is this MIT / LGPL / GPL?
Could you detail that so it's more obvious as to how/if it can be used in other projects?

I feel since it leans on https://github.com/agl/curve25519-donna it might use a similar BSD style license as well
https://github.com/agl/curve25519-donna/blob/master/LICENSE.md

Best regards many thanks,

Bastian

I see curved25519_scalarmult_basepoint in order to generate public keys but the library is missing curved25519_scalarmult.

This lib seems to have incredible performance! Thank you!

I'm very much a c/c++ noob, and I'm having trouble compiling.

First, I can't find the -mbits flag. What is the usage for g++/gcc?

Also, is it OK not to use the -m32 or -m64 flags and allow the compiler to discover the CPU itself?

Also, I really have no idea how to link your library except at a very superficial level. Can you please show me how?

Crosspost: http://stackoverflow.com/questions/21858228/how-to-properly-link-ed25519-donna-with-c-where-is-the-mbits-flag

I desire to cabalize (make into a Haskell library by way of FFI bindings) ed25519-donna for my own use. In doing so I would rather leverage your repository as-is instead of either applying patches as part of a build process or forking and maintaining the changes in a separate repository.

To me, the issues with wrapping FFI around ed25519 all stem from the assumption of OpenSSL, which I can't assume my users have or want. The two issues are SHA512 and RAND_bytes.

• SHA512: I can use the reference implementation, but it shouldn't be an issue to provide my own and define the right symbol as you have documented. Thank you.
• RAND_bytes: The assumption that a cryptographic random number source is available at this low a level is hard to deal with. It would be easier if the interface were divided up into two parts: one that needs RAND_bytes (existing open_batch) and one that accepts sufficient randoms passed in as an argument (open_batch_pure). The first could call the second and possibility be omitted by CPP, morally NO_OPENSSL or some such.

What are your thoughts? I'd be happy to submit a pull-request that pulls out the pure code into an open_batch_pure function and add the mentioned CPP option.

I'm getting strange results with ed25519_sign_open_batch vs ed25519_sign_open.

I'm generating signatures with your library and js-nacl, and I've tried to follow your batch example as best as I can despite my inexperience.

In this case, I'm verifying 3 signatures. The arrays for batch verification are built from a single loop except for the first position in the array.

When verifying individually, all check out. The total batch verification does not return 0. The first in the valid array returns 1, the second 0, and the third 1.

I noticed from the docs that /* valid[i] will be set to 1 if the individual signature was valid, 0 otherwise */. Is that correct?

Regardless of what the values are, it returns in this same pattern, but I always have 3 signatures to batch verify for easy testing. I could setup a larger test, but that would take some time.

Am I doing something obviously wrong based upon this information?

Thank you so much for this great library! The individual signing and verifying is incredibly fast!

floodberry,

Again, I can't thank you enough for this amazingly fast lib!

I'm a big time noob and know enough just to be dangerous. Is this library thread safe in c++?

I do nothing but use the variables and functions outlined in the readme.

Thank you so much in advance!

I've forked this code to add Diffie-Hellman key exchange, so the same keypair can be used for signing and encryption (primitive ge25519_scalarmult; I've first written a variable time scalarmult derived from the verifying code, to make sure the constant time one does the same thing).

The other thing I changed is that I can compile a shared library consisting only of the primitives, not the signing/verifying code itself; as I use SHA-3/Keccak as hash, keeping the actual signature function out of the primitive library makes those experiments easier.

I've also experimented with a high-level implementation that makes GCC generate cmove instructions for the constant time array loads, which does about the same thing as your recently written assembler code; though I use less registers (3 or 4, because starting with 5, gcc thinks a branch is better).

BTW: You don't need to load into a register first, CMOVcc always reads, so you can use a mem operand. Andy Glew originally wanted it to actually load conditionally, but that request was denied, so cmove reg, mem is fine for crypto code - it will always load from mem, regardless of the condition.

floodberry,

I can't thank you enough for this code! It's so fast and even easy enough for a noob like me to use!

I noticed that ref10 omitted the check for Sϵ{0,1...l-1}. I also happily noticed that in the fuzz section, ref10 has to be imported. Since it's reasonable to assume that you did not use ref10, is it reasonable to assume that you did not omit that check?

Also, is this written from scratch against the authors' paper describing the conditions for EdDSA? http://ed25519.cr.yp.to/ed25519-20110926.pdf

Thank you so very much for this lib floodberry!

Submit your implementations to SUPERCOP to enable easy comparisons on many different platforms on the eBACS website.

I've been able to produce the same public key from seed on both, but the signatures do not match up.

tonyg says that his library manages C-language interface's padding requirements. tonyg/js-nacl#27

Do I need to compensate somehow in my c++ code? I don't think I'm converting from strings to const unsigned char*s incorrectly because couting both prints the same to the terminal.

Crosspost: http://stackoverflow.com/questions/22032282/uint8array-equivalent-of-a-c-string-converted-to-const-unsigned-char

ED25519_CUSTOMRNG

vs

ED25519_CUSTOMRANDOM