Subject: [Cfrg] Server hardware acceleration....

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Aug 2014 10:06:15 -0400

One issue that I had overlooked in earlier messages is that while ECC
is generally faster than RSA this is only true if we are comparing
like with like, i.e. ECDH with DH, ECDSA with DSA.

The rub here is that while RSA is fast for public values and slow for
private, DSA is the other way around.  RSA2048 signature verification
is actually faster than DSA with the 512 bit NIST curves by a factor
of 8 roughly. Key agreement is a lot faster though.

Another difference that is likely to have a large impact on the APIs
is that we are not talking about doing ECC encryption, nor do we need
it. We are actually talking about ECC key agreement. So unlike in the
RSA case, the encryption and decryption routines are not direct
inverses. We don't 'encrypt with the private key' to sign as some
people describe it.

Now the performance difference might actually be better. The decision
to deploy TLS is taken by the server, not the client. And since we can
do 600 signature verifications/sec on a middling box on the slow NIST
curves, the disadvantage to the client is not a major concern.

I don't have figures for how much faster the server operations get but
it looks like its at least 20 times faster on the NIST curves and
thats before we start choosing the curves cleverly or doing
precalculations on the static keys.

So the need for hardware acceleration is arguably open.

But if we do want hardware acceleration:
https://www.pgroup.com/lit/articles/insider/v2n1a5.htm

Most machines sold today already have a co-processor with a 512 bit
data bus on them. Going above 512 is going to be really hard for a
long time and if you miss and have to do two fetches you take twice as
long.

I think that is a convincing argument against E521 if we accept the
need for hardware acceleration. But as I point out, that might not be
a major concern.

Those processors could be a good way to provide side channel
resistance though. If you have 1024 cores at 32 bits each and you gang
16 of them together to do one 512 bit ECC calculation, you can do 64
operations in parallel. That could be 64 operations with the same key
or 64 operations with 63 dummy keys.