ni...@lysator.liu.se (Niels Möller) writes:
> Wim Lewis writes:
>
>> Now that 3.5.1 is out, is there a chance this could be looked at?
> Not sure in which order to do things. Maybe it will be best to first add
> the square root routines, with tests, and then add functions for
> converting
ni...@lysator.liu.se (Niels Möller) writes:
> Not sure in which order to do things. Maybe it will be best to first add
> the square root routines, with tests, and then add functions for
> converting between points and octet strings (and related utilities, if
> needed).
I've now pushed some
Wim Lewis writes:
> Now that 3.5.1 is out, is there a chance this could be looked at?
I'd like to have a closer look soon.
> On Wed, May 29, 2019 at 01:25:08AM -0700, Wim Lewis wrote:
>> I've pushed some work-in-progress to a git repository here:
>> https://git.lysator.liu.se/wiml/nettle
Is
Now that 3.5.1 is out, is there a chance this could be looked at?
On Wed, May 29, 2019 at 01:25:08AM -0700, Wim Lewis wrote:
I've pushed some work-in-progress to a git repository here:
https://git.lysator.liu.se/wiml/nettle
On Thursday, June 6, 2019 11:41:49 PM PDT, Wim Lewis wrote:
I've
(Background: I'd been confused by not getting the results I expected from
ecc_mod_sqr(), etc., and wrote to Niels Möller to ask about it)
On Saturday, May 25, 2019 1:15:27 AM PDT, Niels Möller wrote:
The thing is, ->reduce will be either a mod operation or a montgomery
redc operation,
On Thursday, May 23, 2019 3:54:08 PM PDT, Wim Lewis wrote:
One motivation for putting this code into Hogweed is that the
common curves (P-256, -384, -512) all have primes which allow
using a simple shortcut for computing square roots instead of
using a general algorithm. If this is true for
Wim Lewis writes:
> Point compression is easy enough, but point decompression requires
> some curve math, potentially dependent on the specific curve, and some
> of it is redundant with what's already done in ecc_point_set().
I think what's needed is basically a mod p square root. See RFC 6090
