Hello Niels, Thank you very much for all the Curve448/SHAKE256 work for merging (I'm slowly catching up).
ni...@lysator.liu.se (Niels Möller) writes: > ni...@lysator.liu.se (Niels Möller) writes: > >> Daiki Ueno <u...@gnu.org> writes: >> >>> For curve25519, q is defined as: >>> >>> 2^252 + 0x14def9dea2f79cd65812631a5cf5d3ed >>> >>> whose bit pattern starts with 0x1000, so r - q * (r>>252) should >>> work. >>> >>> On the other hand, for curve448, q is defined as: >>> >>> 2^446 - 0x8335dc163bb124b65129c96fde933d8d723a70aadc873d6d54a7bb0d >>> >>> whose bit pattern starts with 0xFFFF. In that case the formula (r - q * >>> (r>>445)) could be incorrect due to the accumulated errors by >>> multiplication (i.e. q * 0x7FFF...). >> >> Good catch! Right, this needs a bit more analysis. Fur curve25519, the >> subtraction can underflow (unlikely), which is addressed with the >> conditional addition a few lines down. > > For ecc_ah_to_a, this code was deleted, but it's still an issue for > eddsa_sign. Maybe need special cases for both ed25519 and ed448 for now. > Or some logic looking at the high limb of q. > > These corner cases are a bit hard to test. For what it's worth, the original issue was reliably reproducible with the GnuTLS port[1] against the OpenSSL client. Here is a test vector extracted from the interaction: test_one ("0cf87eb094bf46d161bde3b99d1d32856fecfae0142392cd98c091db206d174bbf8ef476a9cf746d94306c565f97ac50796f021eff8d779ca5" "9addde61f668f2dbc0ac24874adb47a2aa6ad59fa888bdc5d430705ed0796a8c330782b51860785be63fd79b1c7cf58fd728b2bf3d77395100:" "9addde61f668f2dbc0ac24874adb47a2aa6ad59fa888bdc5d430705ed0796a8c330782b51860785be63fd79b1c7cf58fd728b2bf3d77395100:" "20202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020544c5320312e332c207365727665722043657274696669636174655665726966790090da2c6178a3019274ed029ba5ad28f25662a78d71e8429c19f96007df39d7a77d7cb80f221c76db5e1c397714f48692:" "91554b9b85058d3d6885997adf47e1f766ae780018ca26873de854fb12d789f3bf1f85d3ce5b23265d8d8900f62906e2eb4a064887beaf00009cea26f0edeff35be1e969df77ab1368ced966beb0c7b6242aa0d8844d773e254cfed823d3a5e53b3ef557e716ce7cc2aaca127e86798f2b00" "20202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020544c5320312e332c207365727665722043657274696669636174655665726966790090da2c6178a3019274ed029ba5ad28f25662a78d71e8429c19f96007df39d7a77d7cb80f221c76db5e1c397714f48692:"); >> It might make sense to instead add a function pointer to struct >> ecc_modulo to do canonical reduction; that's needed in a few different >> places, not only here. > > I still think think this makes sense, but it's not clear to me what the > usage really is. Regards, Footnotes: [1] https://gitlab.com/gnutls/gnutls/merge_requests/984 -- Daiki Ueno _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs