simon-git: putty (master): Simon Tatham

Tue May 3 15:00:09 BST 2016

TL;DR:
  d47be8d Swap endianness of the Curve25519 ECDH private key.

Repository:     git://git.tartarus.org/simon/putty.git
On the web:     http://tartarus.org/~simon-git/gitweb/?p=putty.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2016-05-03 15:00:09

commit d47be8d91a0395f521f91e653196d2ad64802a74
web diff http://tartarus.org/~simon-git/gitweb/?p=putty.git;a=commitdiff;h=d47be8d91a0395f521f91e653196d2ad64802a74;hp=dcf44663057ec4df3581f8fd2a31c65a98e6988a
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue May 3 14:44:00 2016 +0100

    Swap endianness of the Curve25519 ECDH private key.

    DJB's spec at http://cr.yp.to/ecdh/curve25519-20060209.pdf is clear
    that we should be clearing the low 3 bits of the _LSB_ of the private
    key bit string, and setting bit 6 and clearing bit 7 of the _MSB_. We
    were doing the opposite, due to feeding the resulting bit string to
    bignum_from_bytes() rather than bignum_from_bytes_le().

    This didn't cause an interoperability issue, because the two DH
    exponentiations still commute, but it goes against the Curve25519
    spec, in particular the care taken to fix the position of the leading
    exponent bit.

    The code is now consistent with the test vectors in RFC 7748 section
    6.1: if you modify the EC_MONTGOMERY branch of ssh_ecdhkex_newkey() to
    replace the loop on random_byte() with a memcpy that fills bytes[]
    with 77076d0a7318a57d3c16c17251b26645df4c2f87ebc0992ab177fba51db92c2a
    and then print out the resulting publicKey->x, you find that it's
    (byte-reversed) the expected output value given in that RFC section,
    8520f0098930a754748b7ddcb43ef75a0dbf3a0d26381af4eba4a98eaa9b4e6a.

 sshecc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)