You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 

340 lines
15 KiB

  1. March 1, 2015:
  2. While by no means complete or stable, I've done most of the ground
  3. work to implement the "Decaf" point encoding. This point encoding
  4. essentially divides the cofactor by 4, turning Goldilocks (or
  5. Ridinghood or E-521) into a prime-order group. Furthermore, like
  6. the Goldilocks encoding, this encoding avoids incompleteness in
  7. the twisted Edwards formulas with a=-1 by sticking to the order-2q
  8. subgroup.
  9. Because the group is prime order, and because the "isogeny strategy"
  10. is not needed, the decaf API can be very simple. I'm still working
  11. on exactly what it should be though. The goal is to have a single-
  12. file (or a few files) for a "ref" version, which is designed for
  13. auditability. The ref version won't be quite so simple as TweetNaCl,
  14. but nearly so simple and much better commented. Then there can also
  15. be an optimized version, perhaps per-platform, which is as fast as
  16. the original Goldilocks code but hopefully still simpler.
  17. I'm experimenting with SHAKE as the hash function here. Possibly I
  18. will also add Keyak as an encryption primitive, so that everything
  19. can be based on Keccak-f, but I'm open to suggestions. For example,
  20. if there's a way to make BLAKE2 as simple and useful as SHAKE
  21. (including in oversized curves like E-521), then the extra speed
  22. would certainly be welcome.
  23. October 27, 2014:
  24. Added more support for >512-bit primes. Changed shared secret
  25. to not overflow the buffer in this case. Changed hashing to
  26. SHA512-PRNG; this doesn't change the behavior in the case that
  27. only one block is required.
  28. E-521 appears to be working. Needs more testing, and maybe some
  29. careful analysis since the carry-handling bounds are awfully tight
  30. under the current analysis (the "< 5<<57" that it #if0 asserts is
  31. not actually tight enough under the current analysis; need
  32. it to be < (1+epsilon) << 59).
  33. So you actually do need to reduce often, at least in the x86_64_r12
  34. version.
  35. p521/arch_ref64: simple and relatively slow impl. Like
  36. p448/arch_ref64, this arch reduces after every add or sub.
  37. p521/arch_x86_64_r12: aggressive, fast implementation. This impl
  38. stores 521 bits not in 9 limbs, but 12! Limbs 3,7,11 are 0, and
  39. are there only for vector alignment. (TODO: remove those limbs
  40. from precomputed tables, so that we don't have to look them up!).
  41. The carry handling on this build is very tight, and probably could
  42. stand more analysis. This is why I have the careful balancing of
  43. "hexad" and "nonad" multiplies in its Chung-Hasan mul routine.
  44. (TODO: reconsider whether this is even worthwhile on machines
  45. without AVX2.)
  46. The 'r12 build is a work in progress, and currently only works on
  47. clang (because it rearranges vectors in the timesW function).
  48. Timings for the fast, aggressive arch on Haswell:
  49. mul: 146cy
  50. sqr: 111cy
  51. invert: 62kcy
  52. keygen: 270kcy
  53. ecdh: 803kcy
  54. sign: 283kcy
  55. verif: 907kcy
  56. Same rules as other Goldi benchmarks. Turbo off, HT off,
  57. timing-channel protected (no dataflow from secrets to branches,
  58. memory lookups or known vt instructions), compressed points.
  59. October 23, 2014:
  60. Pushing through changes for curve flexibility. First up is
  61. Ed480-Ridinghood, because it has the same number of words. Next
  62. is E-521.
  63. Experimental support for Ed480-Ridinghood. To use, compile with
  64. make ... FIELD=p480 -XCFLAGS=-DGOLDI_FIELD_BITS=480
  65. I still need to figure out what to do about the fact that the library
  66. is called "goldilocks", but in will soon support curves that are not
  67. ed448-goldilocks, at least experimentally.
  68. Currently the whole system's header "goldilocks.h" doesn't have
  69. a simpler way to override field size, but it does work (as a hack)
  70. with -DGOLDI_FIELD_BITS=...
  71. There is no support yet for coexistence of multiple fields in one
  72. library. The field routines will have unique names, but scalarmul*
  73. won't, and the top-level goldilocks routines have fixed names.
  74. Current timings on Haswell:
  75. Goldilocks: 178kcy keygen, 536kcy ecdh
  76. Ridinghood: 193kcy keygen, 617kcy ecdh
  77. Note that Ridinghood ECDH does worse than 480/448. This is at least
  78. in part because I haven't calculated the overflow handling limits yet
  79. in ec_point.h (this is a disadvantage of dropping the automated
  80. tool for generating that file). So I'm reducing much more often
  81. than I need to. (There's a really loud TODO in ec_point.h for that.)
  82. Also, I haven't tested the limits on these reductions in a while, so
  83. it could be that there are actual (security-critical) bugs in this
  84. area, at least for p448. Now that there's field flexibility, it's
  85. probably a good idea to make a field impl with extra words to check
  86. this.
  87. Furthermore, field_mulw_scc will perform differently on these two
  88. curves based on whether the curve constant is positive or negative.
  89. I should probably go optimize the "hot" routines like montgomery_step
  90. to have separate cases for positive and negative.
  91. September 29, 2014:
  92. Yesterday I put in some more architecture detection, but it should
  93. really be based on the arch directory, because what's in there really
  94. was a terrible hack. So I've changed it to use $arch/arch_config.h
  95. to get WORD_BITS.
  96. I've tweaked the eBAT construction code to rename the architectures
  97. using test/batarch.map. Maybe I should also rename them internally,
  98. but not yet.
  99. I added some new TODO.txt items. Some folks have been asking for a
  100. more factored library, instead of this combined arithmetic, curve code,
  101. encodings and protocol all-in-one jumble. Likewise the hash and RNG
  102. should be flexible.
  103. I've also been meaning to put more work in on SPAKE2EE, which would
  104. also mean finalizing the Elligator code.
  105. September 18, 2014:
  106. Begin work on a "ref" implementation. Currently this is just the
  107. arch_ref64 architecture. The ref implementation always weak_reduces
  108. after arithmetic, and doesn't use vectors or other hackery. Currently
  109. it still must declare field elements as vector aligned, though,
  110. other code outside the arch directory can be vectorized.
  111. Change goldilocks.c to use field_eq instead of calling deep into field
  112. apis.
  113. September 6, 2014:
  114. Pull in minor changes from David Leon Gil and Nicholas Wilson, with
  115. some adjustments. I hope the adjustments don't break their compiles.
  116. `make bat` now makes a bat which passes supercop-fastbuild, though
  117. the benchmarks are rather different from `make bench`. I need to track
  118. down why.
  119. August 4, 2014:
  120. Experiments and bug fixes.
  121. Add really_memset = memset_s (except not because I'm setting -std=c99),
  122. thanks David Leon Gil. I think I put it in the right places.
  123. Try to work around what I think is a compiler bug in GCC -O3 on non-AVX
  124. platforms. I can't seem to work around it as -Os, so I'm just flagging
  125. a warning (-Werror makes it an error) for now. Will take more
  126. investigation. Thanks Samuel Neves.
  127. Added an experimental (not ready yet!) ARM NEON implementation in
  128. arch_neon_experimental. This implementation seems to work, but needs
  129. more testing. It is currently asm-heavy and not GCC clean. I am
  130. planning to have a flag for it to use intrinsics instead of asm;
  131. currently the intrinsics are commented out. On clang this does ECDH
  132. in 1850kcy on my BeagleBone Black, comparable to Curve41417. Once this
  133. is ready, I will probably move it to arch_neon proper, since arch_neon
  134. isn't particularly tuned.
  135. July 11, 2014:
  136. This is mostly a cleanup release.
  137. Added CRANDOM_MIGHT_IS_MUST config flag (default: 1). When set, this
  138. causes crandom to assume that all features in the target arch will
  139. be available, instead of detecting them. This makes sense because
  140. the rest of the Goldilocks code is not (yet?) able to detect features.
  141. Also, I'd like to submit this to SUPERCOP eventually, and SUPERCOP won't
  142. pass -DMUST_HAVE_XXX on the command line the way the Makefile here did.
  143. Flag EXPERIMENT_CRANDOM_BUFFER_CUTOFF_BYTES to disable the crandom
  144. output buffer. This buffer improves performance (very marginally at
  145. Goldilocks sizes), but can cause problems with forking and VM
  146. snapshotting. By default, the buffer is now disabled.
  147. I've slightly tweaked the Elligator implementation (which is still
  148. unused) to make it easier to invert. This makes anything using Elligator
  149. (i.e. nothing) incompatible with previous releases.
  150. I've been factoring "magic" constants such as curve orders, window sizes,
  151. etc into a few headers, to reduce the effort to port the code to other
  152. primes, curves, etc. For example, I could test the Microsoft curves, and
  153. something like:
  154. x^2 + y^2 = 1 +- 5382[45] x^2 y^2 mod 2^480-2^240-1
  155. ("Goldeneye"? "Ridinghood"?) might be a reasonable thing to try for
  156. 64-bit CPUs.
  157. In a similar vein, most of the internal code has been changed to say
  158. "field" instead of p448, so that a future version of magic.h can decide
  159. which field header to include.
  160. You can now `make bat` to create an eBAT in build/ed448-goldilocks. This
  161. is only minimally tested, though, because SUPERCOP doesn't work on my
  162. machine and I'm too lazy to reverse engineer it. It sets a new macro,
  163. SUPERCOP_WONT_LET_ME_OPEN_FILES, which causes goldilocks_init() to fall
  164. back to something horribly insecure if crandom_init_from_file raises
  165. EMFILE.
  166. Slightly improved documentation.
  167. Removed some old commented-out code; restored the /* C-style */ comment
  168. discipline.
  169. The AMD-64 version should now be GCC clean, at least for reasonably
  170. recent GCC (tested on OS X.9.3, Haswell, gcc-4.9).
  171. History no longer says "2104".
  172. May 3, 2014:
  173. Minor changes to internal routines mean that this version is not
  174. compatible with the previous one.
  175. Added ARM NEON code.
  176. Added the ability to precompute multiples of a partner's public key. This
  177. takes slightly longer than a signature verification, but reduces future
  178. verifications with the precomputed key by ~63% and ECDH by ~70%.
  179. goldilocks_precompute_public_key
  180. goldilocks_destroy_precomputed_public_key
  181. goldilocks_verify_precomputed
  182. goldilocks_shared_secret_precomputed
  183. The precomputation feature are is protected by a macro
  184. GOLDI_IMPLEMENT_PRECOMPUTED_KEYS
  185. which can be #defined to 0 to compile these functions out. Unlike most
  186. of Goldilocks' functions, goldilocks_precompute_public_key uses malloc()
  187. (and goldilocks_destroy_precomputed_public_key uses free()).
  188. Changed private keys to be derived from just the symmetric part. This
  189. means that you can compress them to 32 bytes for cold storage, or derive
  190. keypairs from crypto secrets from other systems.
  191. goldilocks_derive_private_key
  192. goldilocks_underive_private_key
  193. goldilocks_private_to_public
  194. Fixed a number of bugs related to vector alignment on Sandy Bridge, which
  195. has AVX but uses SSE2 alignment (because it doesn't have AVX2). Maybe I
  196. should just switch it to use AVX2 alignment?
  197. Beginning to factor out curve-specific magic, so as to build other curves
  198. with the Goldilocks framework. That would enable fair tests against eg
  199. E-521, Ed25519 etc. Still would be a lot of work.
  200. More thorough testing of arithmetic. Now uses GMP for testing framework,
  201. but not in the actual library.
  202. Added some high-level tests for the whole library, including some (bs)
  203. negative testing. Obviously, effective negative testing is a very difficult
  204. proposition in a crypto library.
  205. March 29, 2014:
  206. Added a test directory with various tests. Currently testing SHA512 Monte
  207. Carlo, compatibility of the different scalarmul functions, and some
  208. identities on EC point ops. Began moving these tests out of benchmarker.
  209. Added scan-build support.
  210. Improved some internal interfaces. Made a structure for Barrett primes
  211. instead of passing parameters individually. Moved some field operations
  212. to places that make more sense, eg Barrett serialize and deserialize. The
  213. deserialize operation now checks that its argument is in [0,q).
  214. Added more documentation.
  215. Changed the names of a bunch of functions. Still not entirely consistent,
  216. but getting more so.
  217. Some minor speed improvements. For example, multiply is now a couple cycles
  218. faster.
  219. Added a hackish attempt at thread-safety and initialization sanity checking
  220. in the Goldilocks top-level routines.
  221. Fixed some vector alignment bugs. Compiling with -O0 should now work.
  222. Slightly simplified recode_wnaf.
  223. Add a config.h file for future configuration. EXPERIMENT flags moved here.
  224. I've decided against major changes to SHA512 for the moment. They add speed
  225. but also significantly bloat the code, which is going to hurt L1 cache
  226. performance. Perhaps we should link to OpenSSL if a faster SHA512 is desired.
  227. Reorganize the source tree into src, test; factor arch stuff into src/arch_*.
  228. Make most of the code 32-bit clean. There's now a 32-bit generic and 32-bit
  229. vectorless ARM version. No NEON version yet because I don't have a test
  230. machine (could use my phone in a pinch I guess?). The 32-bit version still
  231. isn't heavily optimized, but on ARM it's using a nicely reworked signed/phi-adic
  232. multiplier. The squaring is also based on this, but could really stand some
  233. improvement.
  234. When passed an even exponent (or extra doubles), the Montgomery ladder should
  235. now be accept points if and only if they lie on the curve. This needs
  236. additional testing, but it passes the zero bit exponent test.
  237. On 32-bit, use 8x4x14 instead of 5x5x18 table organization. Probably there's
  238. a better heuristic.
  239. March 5, 2014:
  240. First revision.
  241. Private keys are now longer. They now store a copy of the public key, and
  242. a secret symmetric key for signing purposes.
  243. Signatures are now supported, though like everything else in this library,
  244. their format is not stable. They use a deterministic Schnorr mode,
  245. similar to EdDSA. Precomputed low-latency signing is not supported (yet?).
  246. The hash function is SHA-512.
  247. The deterministic hashing mode needs to be changed to HMAC (TODO!). It's
  248. currently envelope-MAC.
  249. Probably in the future there will be a distinction between ECDH key and
  250. signing keys (and possibly also MQV keys etc).
  251. Began renaming internal functions. Removing p448_ prefixes from EC point
  252. operations. Trying to put the verb first. For example,
  253. "p448_isogeny_un_to_tw" is now called "twist_and_double".
  254. Began documenting with Doxygen. Use "make doc" to make a very incomplete
  255. documentation directory.
  256. There have been many other internal changes.
  257. Feb 21, 2014:
  258. Initial import and benchmarking scripts.
  259. Keygen and ECDH are implemented, but there's no hash function.