On 7/21/21 9:06 AM, Hannes Reinecke wrote:

On 7/20/21 10:26 PM, Vladislav Bolkhovitin wrote:

quoted

Hi,

Great to see those patches coming! After some review, they look to be
very well done. Some comments/suggestions below.

1. I strongly recommend to implement DH exponentials reuse (g x mod p /
g y mod p as well as g xy mod p) as specified in section 8.13.5.7
"DH-HMAC-CHAP Security Requirements". When I was working on TP 8006 I
had a prototype that demonstrated that DH math has quite significant
latency, something like (as far as I remember) 30ms for 4K group and few
hundreds of ms for 8K group. For single connection it is not a big deal,
but imagine AMD EPYC with 128 cores. Since all connections are created
sequentially, even with 30 ms per connection time to complete full
remote device connection would become 128*30 => almost 4 seconds. With
8K group it might be more than 10 seconds. Users are unlikely going to
be happy with this, especially in cases, when connecting multiple of
NVMe-oF devices is a part of a server or VM boot sequence.

Oh, indeed, I can confirm that. FFDHE calculations are quite time-consuming.
But incidentally, ECDH and curve25519 are reasonably fast,

Yes, EC calculations are very fast, this is why EC cryptography is
gaining more and more popularity.

so maybe
there _is_ a value in having a TPAR asking for them to be specified, too ...

There's too much politics and procedures involved here. Even in the
current scope it took more, than 2 years to get the spec officially done
(I started proposing it early 2018). Maybe, in future, if someone comes
in the the committee with the corresponding proposal and value
justification.

Although, frankly speaking, with DH exponentials reuse I personally
don't see much value in ECDH in this application. Maybe, only for very
small embedded devices with really limited computational capabilities.

quoted

If DH exponential reuse implemented, for all subsequent connections the
DH math is excluded, so authentication overhead becomes pretty much
negligible.

In my prototype I implemented DH exponential reuse as a simple
per-host/target cache that keeps DH exponentials (including g xy mod p)
for up to 10 seconds. Simple and sufficient.

Frankly, I hadn't looked at exponential reuse; this implementation
really is just a first step to get feedback from people if this is a
direction they want to go.

Sure, I understand.

quoted

Another, might be ever more significant reason why DH exponential reuse
is important is that without it x (or y on the host side) must always be
randomly generated each time a new connection is established. Which
means, for instance, for 8K groups for each connection 1KB of random
bytes must be taken from the random pool. With 128 connections it is now
128KB. Quite a big pressure on the random pool that DH exponential reuse
mostly avoids.

Those are the 2 reasons why we added this DH exponential reuse sentence
in the spec. In the original TP 8006 there was a small informative piece
explaining reasonings behind that, but for some reasons it was removed
from the final version.

Thanks for the hint. I'll be adding exponential reuse to the code.

Yes, please. Otherwise, people might start talking that Linux NVMe-oF
authentication is too bad and slow.

Vlad