<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 13, 2015, at 6:09 AM, Watson Ladd <<a href="mailto:watsonbladd@gmail.com" class="">watsonbladd@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class=""><br class=""> On Nov 13, 2015 8:44 AM, "Nicholas Wilson" <<a href="mailto:nicholas@nicholaswilson.me.uk" class="">nicholas@nicholaswilson.me.uk</a>> wrote:<br class=""> ><br class=""> > Hi,<br class=""> ><br class=""> > I have some questions about implementing Curve448, having implemented<br class=""> > it for mbedTLS in a pull request here:<br class=""> > <a href="https://github.com/ARMmbed/mbedtls/pull/348" class="">https://github.com/ARMmbed/mbedtls/pull/348</a><br class=""> ><br class=""> > I've been following the discussion around the IRTF standard, but I'm<br class=""> > still not quite sure what the recommended behaviour is for validating<br class=""> > public points.<br class=""> ><br class=""> > In the latest standard, regarding public u-values:<br class=""> ><br class=""> > "When receiving such an array, implementations of X25519 (but not<br class=""> > X448) MUST mask the most-significant bit in the final byte."<br class=""> > (<a href="https://tools.ietf.org/html/draft-irtf-cfrg-curves-11#section-4.2" class="">https://tools.ietf.org/html/draft-irtf-cfrg-curves-11#section-4.2</a><br class=""> ><br class=""> > This suggests, but doesn't state, that implementations shouldn't do<br class=""> > any masking for Curve448, but should instead just reduce the public<br class=""> > value mod P448 (or issue an error if it's not in canonical form,<br class=""> > probably my preferred implementation choice). Is that correct?</p><p dir="ltr" class="">Yes. But note that Curve448 is designed to work correctly with all inputs. There are issues with TLS because of requirements on contributory behavior.</p><div class=""><br class=""></div></div></blockquote><div><br class=""></div><div>Right. The X448 spec says not to error out except on small-order points (i.e. ones that give you 0 as output). Whether the small-order points are a problem or not depends on your protocol; for some protocols it may be safe to ignore the error return and use the 0 output.</div><blockquote type="cite" class=""><div class=""><p dir="ltr" class=""> > Secondly, I have a question about the implementation of the arithmetic<br class=""> > itself. I've had a hunt for Mike's various papers and presentations on<br class=""> > Ed448-Goldilocks, and I think I understand the rationale for the<br class=""> > choice of prime. What I can't find though is a simple do-this-do-that<br class=""> > guide for implementers, like NIST publishes for their primes.</p><p dir="ltr" class="">NIST guide is hard to make constant time. I'm not Mike, but as I recall the division is into 56 bit limbs to avoid carries and permit vectorised additions. The formula isn't that hard to work out from there: it's a matter of adding the top pieces to the bottom in the right places. Safety analysis is a bit trickier.</p><p dir="ltr" class="">The big benefit is you avoid carries and dependent instruction chains.</p></div></blockquote>Right. If you already have an engine that does all the NIST primes in a modular way (eg in hardware), then you can use the NIST approach, but otherwise reduced radix is the way to go.<br class=""><blockquote type="cite" class=""><p dir="ltr" class=""> > In the end, I've come up with my own modular reduction formula after<br class=""> > playing around with the equations, and it seems to be reasonable<br class=""> > (three 448-sized additions), but I wondered if I'm missing any tricks<br class=""> > that should make it even quicker.<br class=""> ><br class=""> > I'm aware that for 32-bit machines, you can split the numbers up into<br class=""> > 32-bit limbs and write q=2^32, p = q^14 - q^7 - 1 and come up with a<br class=""> > big complex formula to explictly do your reduction in terms of the<br class=""> > limb values.<br class=""> ><br class=""> > I'm more interested in optimising for 64-bit though, so I've chosen to<br class=""> > split the input into four "limbs" of 2^224 and do a few bignum<br class=""> > additions on those limbs, which will use the bignum library's 64-bit<br class=""> > CPU operations, and may come out quicker. The code is certainly<br class=""> > simpler, and I don't think anyone deploying Curve448 really cares<br class=""> > about performance as long as it's "good enough".<br class=""> ><br class=""> > Let N = A0 + 2^448 A1, let A1 = B0 + 2^224 B1. Then N (or N+P) mod P<br class=""> > is A0+A1+B1+(B0+B1)*2^224. This works on paper, and produces the<br class=""> > expected output on the test vectors from the IRTF spec.<br class=""> ><br class=""> > So my question is whether this is the expected reduction formula, or<br class=""> > whether there's some method which is simpler still.<br class=""></p></blockquote><div>This is the expected reduction formula. However, I believe it’s easier to implement Ed448 using reduced radix, where you store 8, 56-bit limbs as 8, 64-bit words with some headroom, and only do the exact reduction at the very end. Maybe this isn’t true in your case because you already have a bignum engine, but it might be worth taking a look.</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div>The simplest multiplication formula I know is the one found in <a href="http://sourceforge.net/p/ed448goldilocks/code/ci/x448/tree/x448.c" class="">http://sourceforge.net/p/ed448goldilocks/code/ci/x448/tree/x448.c</a> though it’s macro’d up so that it works for both 32- and 64-bit limbs. You use an array of 8, 128-bit accumulators. Instead of multiplying AxB and then reducing, at each step you multiply A by the i’th digit of B and add to the accumulators, and then you multiply A by 2^56 and reduce in place.</div><div><br class=""></div><div>The in-place multiplication is done up to logical shifting. That is, if you have A = A0, A1, A2, A3, A4, A5, A6, A7, then A*2^56 = (A7, A0, A1, A2, A3+A7, A4, A5, A6): it’s a rotation of A with one addition. But there’s no need to actually rotate A by one position: it’s better to just adjust your indexing.</div><div><br class=""></div><div>At the end you propagate the carries in the accumulators.</div><div><br class=""></div><div>The same algorithm can be used with product-scanning, where you first compute accum[0], then accum[1], and so on. This might work better on x86 since it doesn’t actually have eight 128-bit registers. But I think the compiler will treat the two as almost the same anyway, at least if the loops are unrolled and optimizations are on. The usual difference between product-scanning and operand-scanning is the carry propagation, but here they’re only propagated at the end. The other difference is just the order you do the multiplications in, but the compiler will completely reorder them anyway.</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div>P448 is also designed to support a relatively simple Karatsuba multiplication algorithm, which should take about 20% less time. The version at <a href="http://sourceforge.net/p/ed448goldilocks/code/ci/decaf/tree/src/p448/arch_ref64/p448.c" class="">http://sourceforge.net/p/ed448goldilocks/code/ci/decaf/tree/src/p448/arch_ref64/p448.c</a>, p448_mul, is the closest thing I have to a plan of record for that one. But of course, the “schoolbook” method is simpler. Note also that in this version, c is __restrict__ because we start writing results to it before we’re done with a and b.</div><div><br class=""></div><div>The simpler multiplication algorithm in x448.c is not especially easy to turn into a dedicated squaring algorithm. But if you want the performance increase of a dedicated squarer, then you probably want Karatsuba too.</div><blockquote type="cite" class=""><p dir="ltr" class=""> > Thanks for your help,<br class=""> > Nick<br class=""></p></blockquote><br class=""></div><div>Cheers,</div><div>— Mike</div></body></html>