Re: LTC + ECC + VROOM == v1.12

D. J. Bernstein wrote:
Anyone who cares about speed will be reusing one Diffie-Hellman secret
key to compute many shared secrets. This means that one fixed-point
scalar multiplication is accompanied by a huge number of variable-point
scalar multiplications. That's why

Again wrong. Signatures are a big part of many embedded and server
applications. Things like remote sensors which need to authenticate
data could now use ECC instead of just a MAC with some shared key.
Servers running SSL [or SSL like protocols] could make use of this in
key exchange and setup.

Also, in some embedded cases you can make things asymmetric where you
do encryption on the low power device and decryption on the higher
[e.g. like a cell phone or video game console].

Tom now reports 656215 Athlon-64 cycles for fixed-point scalar
multiplication on the NIST P-224 curve. That's a fairly serious step
backwards from the NIST P-224 code that I published five years ago,
which took 595537 Athlon cycles for variable-point scalar multiplication
on the same curve. I'm not quite sure what Tom means by ``tie'' here.

656K when using 62K of memory. If I bump that up to just under 1MB I
get 494K cycles. That's plenty reasonable for a large segment of
crypto users. Furthermore, at least for server markets I haven't even
threaded this yet. I'm reasonably confident I can hit around 265K
cycles for ECC-224 with a dual-threaded approach.

Meanwhile, the state of the art has moved on to better choices of
curves, specifically Curve25519, achieving considerably higher security
for the same speed. See http://cr.yp.to/ecdh.html for details.

But it's not a standard. What's worse is it's not even portable. You
sacrificed usefulness to get speed. I'm merely trading off memory to
get speed. My fixed point code is entirely portable, agnostic even to
the bignum library you are using and can achieve these results. On my
Pentium M laptop for instance I saw nearly the same improvement ratio
even though I moved from 64-bit to 32-bit mode [and different TFM
configurations too].

Tom

Tom

.

Quantcast