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

[Mike Hamburg]

> On Apr 24, 2016, at 9:42 AM, Alex <alex at centromere.net> wrote:
> 
> On Sat, 23 Apr 2016 22:56:14 -0700
> Mike Hamburg <mike at shiftleft.org> wrote:
> 
>> 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.
>> 
> 
> Hi Mike, thank you for that information.
> 
> The only operation I need is decaf_x448. I copied that sole function to
> a fresh file and attempted to compile it, knowing it would fail. I then
> looked through each error message and pulled in what was missing. This
> procedure was repeated until all symbols were resolved.
> 
> Using the x86_64 arch intrinsics, I was able to achieve a ~60% speed
> increase[0] as compared to your x448 branch[1].
> 
> -- 
> Alex
> 
> [0] http://centromere.github.io/cacophony/benchmarks/XN.html
> [1] http://centromere.github.io/cacophony/benchmarks-old/XN.html

Glad to hear that it worked out for you!  60% less time sounds like a solid gain.

— Mike