[noise] Wiki? (was: Re: Echo server and benchmarks)

[Mike Hamburg]

> On Apr 21, 2016, at 7:41 PM, Alex <alex at centromere.net> wrote:
> 
> On Thu, 21 Apr 2016 16:21:37 -0700
> Trevor Perrin <trevp at trevp.net> wrote:
> 
>> What about having a developer wiki, linked from the website, where we
>> can collect useful resources?  Would this work? -
>> 
>> https://github.com/noiseprotocol/noise_wiki/wiki
> 
> That works. I just added information about the test vectors.
> 
>> The 448 DH looks 5-6x slower than 25519, whereas with equivalent
>> optimization it should only be 3-4x slower.
>> 
> 
> The X448 implementation I'm using is located here[0]. I've contacted
> Mike Hamburg about a faster implementation. He told me that he intends
> to merge the curve25519-work to master after he cleans some things up.
> Unfortunately, I am unable to figure out the layout of his source tree
> and I haven't been able to reach him for further clarification.

Sorry to be so slow in responding.  The motivation of the layout is to get some of the benefits normally associated with C++, without requiring users to link in C++ runtimes etc.  So any file with .tmpl.{c,h,c++,h++} gets filled in by a python script to create a plain c/c++ file in src/GENERATED.  The generated files are checked in so that you don’t need to regenerate them to build (and can build without python, and can read the source on Sourceforge).

The source files are designed as a comprehensive library of point operations, not just support for X448.  So they will include many operations that you don’t need, such as multiplication of scalars by scalars, and double-scalar multiply.  (But some are still potentially useful.  For example, dual-scalar multiply is potentially useful for triple DH.)

You will probably want:

src/utils.c: for secure bzero
src/p448/f_arithmetic.c: code specific to this field but not to any arch.  Inverse and square root power chain.
src/p448/arch_*/f_impl.{c,h}: optimized field arithmetic for various architectures.  Arch_32 for generic 32, arch_ref64 for generic 64.
src/per_field/{f_field.tmpl.h,f_generic.tmpl.c} --> src/GENERATED/c/p448/{f_field.h,f_generic.c}: generic field operations which are templated by field.
src/per_curve/{decaf.tmpl.c,scalar.tmpl.c,point.tmpl.h} --> src/GENERATED/c/ed448goldilocks/%.c, src/GENERATED/include/decaf/%.h: generic operations which are templated per curve.
src/public_include/{common.h} to declare common operations.
src/include/{pretty much everything}
src/GENERATED/c/decaf_tables.c, generated by decaf_gen_tables.tmpl.c: precomputed comb tables for fast keygen.  Also contains WNAF tables for sig verification which you can throw out if you aren’t implementing signing and verification.

Let me know if this still isn’t clear.

Cheers,
— Mike


>> Hmm... I wonder if your hashing is relatively slow compared to 25519?
>> 
> 
> Could be. I am using a 3rd party library[1] for all crypto and haven't
> had the time to investigate performance characteristics too deeply. As
> Haskell is a lazily evaluated language, it makes reasoning about
> performance tricky.
> 
> -- 
> Alex
> 
> [0] https://sourceforge.net/p/ed448goldilocks/code/ci/x448/tree/
> [1] https://github.com/haskell-crypto/cryptonite
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise