1. 01 Jul, 2015 5 commits
  2. 26 Jun, 2015 1 commit
  3. 24 Jun, 2015 3 commits
  4. 23 Jun, 2015 1 commit
  5. 22 Jun, 2015 6 commits
  6. 20 Jun, 2015 1 commit
  7. 19 Jun, 2015 11 commits
  8. 30 May, 2015 1 commit
  9. 28 May, 2015 2 commits
  10. 26 May, 2015 2 commits
  11. 20 May, 2015 1 commit
    • Michael Hamburg's avatar
      Create functions for inverting Elligator. · 0241632a
      Michael Hamburg authored
      I'm kind of torn about this change, because it adds a bunch of
      fairly complex code that's only needed for esoteric use cases,
      and it makes Elligator more complex, if mostly only for testing
      purposes.  Basically, this is because Elligator is approximately
      ~8-to-1 when its domain is 56 bytes: 2 because it's [0..p+small]
      instead of [0..(p-1)/2], and 4 for cofactor removal.  So when you
      call the inverse on a point, you need to say which inverse you want,
      i.e. a "hint".
      Of course, the inverse fails with probability 1/2.
      To make round-tripping a possibility (I'm not sure why you'd need this),
      the Elligator functions now return an unsigned char hint.  This means
      that you can call Elligator, and then invert it with the hint you gave,
      and get the same buffer back out.  This adds a bunch of complexity to
      Elligator, which didn't previously need to compute hints.  The hinting is
      reasonably well tested, but it is known not to work for inputs which are
      very "large", i.e. end ~28 0xFF's (FIXME.  Or roll back hinting...).
      There's also a significant chance that I'll revise the hinting mechanism.
      Create functions:
      for inverting Elligator.  This last one encodes to Point::STEG_BYTES = 64
      bytes in a way which is supposed to be indistinguishable from random, so
      long as your point is random on the curve.
      Inverting Elligator costs about 2 square roots for nonuniform.  For
      uniform, it's just Elligator -> diff -> invert, so it's 3 square roots.
      Stegging fails about half the time, and so costs about twice that, but
      the benchmark underreports it because it ignores outliers.
      The code is tested, but I haven't checked over the indistinguishability
      from random (I've only proved it correct...).  There could well be a way
      to break the steg even without taking advantage of "very large" inputs
      or similar.
  12. 18 May, 2015 1 commit
  13. 06 May, 2015 3 commits
  14. 05 May, 2015 1 commit
  15. 02 May, 2015 1 commit