[Cryptech-Commits] [sw/libhal] branch master updated: Update ECDSA description in README.md -- the point multiplication algorithm hasn't been a Montgomery Ladder for a long time, if indeed it ever was.

[git at cryptech.is]

This is an automated email from the git hooks/post-receive script.

sra at hactrn.net pushed a commit to branch master
in repository sw/libhal.

The following commit(s) were added to refs/heads/master by this push:
       new  1998250   Update ECDSA description in README.md -- the point multiplication algorithm hasn't been a Montgomery Ladder for a long time, if indeed it ever was.
1998250 is described below

commit 19982508bb490f366ce26c71c11391abcbf40e19
Author: Rob Austein <sra at hactrn.net>
AuthorDate: Tue May 10 20:12:53 2016 -0400

    Update ECDSA description in README.md -- the point multiplication
    algorithm hasn't been a Montgomery Ladder for a long time, if indeed
    it ever was.
---
 README.md | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/README.md b/README.md
index 71fc0a0..d4a387e 100644
--- a/README.md
+++ b/README.md
@@ -80,18 +80,19 @@ The current point addition and point doubling algorithms come from the
 [EFD][].  At least at the moment, we're only interested in ECDSA with
 the NIST prime curves, so we use algorithms optimized for a=-3.
 
-The point multiplication algorithm is a Montgomery Ladder, which is
-not the fastest possible algorithm, but is relatively easy to confirm
-by inspection as constant-time.  Point multiplication could probably
-be made faster by using a non-adjacent form (NAF) representation for
-the scalar, but the author doesn't yet understand that well enough to
+The point multiplication algorithm is a straightforward square and add
+loop, which is not the fastest possible algorithm, but is relatively
+easy to confirm by inspection as being constant-time within the limits
+imposed by the NIST curves.  Point multiplication could probably be
+made faster by using a non-adjacent form (NAF) representation for the
+scalar, but the author doesn't yet understand that well enough to
 implement it as a constant-time algorithm.  In theory, changing to a
 NAF representation could be done without any change to the public API.
 
 Points stored in keys and curve parameters are in affine format, but
-all point arithmetic is performed in Jacobian projective coordinates,
-with the coordinates in Montgomery form; final mapping back to affine
-coordinates also handles the final Montgomery reduction.
+point arithmetic is performed in Jacobian projective coordinates, with
+the coordinates themselves in Montgomery form; final mapping back to
+affine coordinates also handles the final Montgomery reduction.
 
 ## API ##
 

-- 
To stop receiving notification emails like this one, please contact
the administrator of this repository.