From: Vladislav Bolkhovitin <vst@vlnb.net> To: Hannes Reinecke <hare@suse.de>, Christoph Hellwig <hch@lst.de> Cc: Sagi Grimberg <sagi@grimberg.me>, Keith Busch <keith.busch@wdc.com>, linux-nvme@lists.infradead.org, Herbert Xu <herbert@gondor.apana.org.au>, "David S . Miller" <davem@davemloft.net>, linux-crypto@vger.kernel.org Subject: Re: [RFC PATCH 00/11] nvme: In-band authentication support Date: Wed, 21 Jul 2021 15:10:17 +0300 [thread overview] Message-ID: <833cfd62-1e1f-1dca-2e38-ff07b3a5e8fb@vlnb.net> (raw) In-Reply-To: <e339e6e7-fc32-2480-ca99-516547105776@suse.de> On 7/21/21 9:06 AM, Hannes Reinecke wrote: > On 7/20/21 10:26 PM, Vladislav Bolkhovitin wrote: >> 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. >> 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. >> 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
WARNING: multiple messages have this Message-ID (diff)
From: Vladislav Bolkhovitin <vst@vlnb.net> To: Hannes Reinecke <hare@suse.de>, Christoph Hellwig <hch@lst.de> Cc: Sagi Grimberg <sagi@grimberg.me>, Keith Busch <keith.busch@wdc.com>, linux-nvme@lists.infradead.org, Herbert Xu <herbert@gondor.apana.org.au>, "David S . Miller" <davem@davemloft.net>, linux-crypto@vger.kernel.org Subject: Re: [RFC PATCH 00/11] nvme: In-band authentication support Date: Wed, 21 Jul 2021 15:10:17 +0300 [thread overview] Message-ID: <833cfd62-1e1f-1dca-2e38-ff07b3a5e8fb@vlnb.net> (raw) In-Reply-To: <e339e6e7-fc32-2480-ca99-516547105776@suse.de> On 7/21/21 9:06 AM, Hannes Reinecke wrote: > On 7/20/21 10:26 PM, Vladislav Bolkhovitin wrote: >> 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. >> 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. >> 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 _______________________________________________ Linux-nvme mailing list Linux-nvme@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2021-07-21 12:11 UTC|newest] Thread overview: 150+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-16 11:04 [RFC PATCH 00/11] nvme: In-band authentication support Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-16 11:04 ` [PATCH 01/11] crypto: add crypto_has_shash() Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 6:08 ` Sagi Grimberg 2021-07-17 6:08 ` Sagi Grimberg 2021-07-16 11:04 ` [PATCH 02/11] crypto: add crypto_has_kpp() Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 6:08 ` Sagi Grimberg 2021-07-17 6:08 ` Sagi Grimberg 2021-07-16 11:04 ` [PATCH 03/11] crypto/ffdhe: Finite Field DH Ephemeral Parameters Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 6:14 ` Sagi Grimberg 2021-07-17 6:14 ` Sagi Grimberg 2021-07-17 13:57 ` Hannes Reinecke 2021-07-17 13:57 ` Hannes Reinecke 2021-07-17 15:03 ` Stephan Müller 2021-07-17 15:03 ` Stephan Müller 2021-07-18 12:22 ` Hannes Reinecke 2021-07-18 12:22 ` Hannes Reinecke 2021-07-16 11:04 ` [PATCH 04/11] lib/base64: RFC4648-compliant base64 encoding Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 6:16 ` Sagi Grimberg 2021-07-17 6:16 ` Sagi Grimberg 2021-07-17 14:00 ` Hannes Reinecke 2021-07-17 14:00 ` Hannes Reinecke 2021-07-17 14:12 ` Eric Biggers 2021-07-17 14:12 ` Eric Biggers 2021-07-17 14:20 ` Eric Biggers 2021-07-17 14:20 ` Eric Biggers 2021-07-16 11:04 ` [PATCH 05/11] nvme: add definitions for NVMe In-Band authentication Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 6:30 ` Sagi Grimberg 2021-07-17 6:30 ` Sagi Grimberg 2021-07-17 14:04 ` Hannes Reinecke 2021-07-17 14:04 ` Hannes Reinecke 2021-07-20 20:26 ` Vladislav Bolkhovitin 2021-07-20 20:26 ` Vladislav Bolkhovitin 2021-07-16 11:04 ` [PATCH 06/11] nvme: Implement " Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 7:22 ` Sagi Grimberg 2021-07-17 7:22 ` Sagi Grimberg 2021-07-18 12:21 ` Hannes Reinecke 2021-07-18 12:21 ` Hannes Reinecke 2021-07-19 8:47 ` Sagi Grimberg 2021-07-19 8:47 ` Sagi Grimberg 2021-07-20 20:28 ` Vladislav Bolkhovitin 2021-07-20 20:28 ` Vladislav Bolkhovitin 2021-07-21 6:12 ` Hannes Reinecke 2021-07-21 6:12 ` Hannes Reinecke 2021-07-17 16:49 ` Stephan Müller 2021-07-17 16:49 ` Stephan Müller 2021-07-18 12:43 ` Hannes Reinecke 2021-07-18 12:43 ` Hannes Reinecke 2021-07-18 12:47 ` Stephan Müller 2021-07-18 12:47 ` Stephan Müller 2021-07-20 20:27 ` Vladislav Bolkhovitin 2021-07-20 20:27 ` Vladislav Bolkhovitin 2021-07-21 6:08 ` Hannes Reinecke 2021-07-21 6:08 ` Hannes Reinecke 2021-07-21 12:10 ` Vladislav Bolkhovitin 2021-07-21 12:10 ` Vladislav Bolkhovitin 2021-07-16 11:04 ` [PATCH 07/11] nvme-auth: augmented challenge support Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 16:49 ` Stephan Müller 2021-07-17 16:49 ` Stephan Müller 2021-07-18 12:27 ` Hannes Reinecke 2021-07-18 12:27 ` Hannes Reinecke 2021-07-18 12:57 ` Stephan Müller 2021-07-18 12:57 ` Stephan Müller 2021-07-19 9:21 ` Sagi Grimberg 2021-07-19 9:21 ` Sagi Grimberg 2021-07-20 13:12 ` Hannes Reinecke 2021-07-20 13:12 ` Hannes Reinecke 2021-07-16 11:04 ` [PATCH 08/11] nvmet: Parse fabrics commands on all queues Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-19 9:21 ` Sagi Grimberg 2021-07-19 9:21 ` Sagi Grimberg 2021-07-16 11:04 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 16:49 ` Stephan Müller 2021-07-17 16:49 ` Stephan Müller 2021-07-18 12:37 ` Hannes Reinecke 2021-07-18 12:37 ` Hannes Reinecke 2021-07-18 12:56 ` Stephan Müller 2021-07-18 12:56 ` Stephan Müller 2021-07-19 8:15 ` Hannes Reinecke 2021-07-19 8:15 ` Hannes Reinecke 2021-07-19 8:51 ` Stephan Mueller 2021-07-19 8:51 ` Stephan Mueller 2021-07-19 9:57 ` Hannes Reinecke 2021-07-19 9:57 ` Hannes Reinecke 2021-07-19 10:19 ` Stephan Mueller 2021-07-19 10:19 ` Stephan Mueller 2021-07-19 11:10 ` Hannes Reinecke 2021-07-19 11:10 ` Hannes Reinecke 2021-07-19 11:52 ` Stephan Mueller 2021-07-19 11:52 ` Stephan Mueller 2021-07-19 12:08 ` Hannes Reinecke 2021-07-19 12:08 ` Hannes Reinecke 2021-07-20 10:14 ` Hannes Reinecke 2021-07-20 10:14 ` Hannes Reinecke 2021-07-20 10:49 ` Simo Sorce 2021-07-20 10:49 ` Simo Sorce 2021-07-20 11:31 ` Hannes Reinecke 2021-07-20 11:31 ` Hannes Reinecke 2021-07-20 14:44 ` Simo Sorce 2021-07-20 14:44 ` Simo Sorce 2021-07-20 14:47 ` Stephan Mueller 2021-07-20 14:47 ` Stephan Mueller 2021-07-23 20:02 ` Vladislav Bolkhovitin 2021-07-23 20:02 ` Vladislav Bolkhovitin 2021-07-18 13:26 ` Herbert Xu 2021-07-18 13:26 ` Herbert Xu 2021-07-19 20:38 ` Sagi Grimberg 2021-07-19 20:38 ` Sagi Grimberg 2021-07-20 6:08 ` Hannes Reinecke 2021-07-20 6:08 ` Hannes Reinecke 2021-07-16 11:04 ` [PATCH 10/11] nvmet-auth: implement support for augmented challenge Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 16:49 ` Stephan Müller 2021-07-17 16:49 ` Stephan Müller 2021-07-18 12:25 ` Hannes Reinecke 2021-07-18 12:25 ` Hannes Reinecke 2021-07-16 11:04 ` [PATCH 11/11] nvme: add non-standard ECDH and curve25517 algorithms Hannes Reinecke 2021-07-16 11:04 ` Hannes Reinecke 2021-07-17 16:50 ` Stephan Müller 2021-07-17 16:50 ` Stephan Müller 2021-07-18 12:44 ` Hannes Reinecke 2021-07-18 12:44 ` Hannes Reinecke 2021-07-19 9:23 ` Sagi Grimberg 2021-07-19 9:23 ` Sagi Grimberg 2021-07-19 9:56 ` Hannes Reinecke 2021-07-19 9:56 ` Hannes Reinecke 2021-07-17 6:06 ` [RFC PATCH 00/11] nvme: In-band authentication support Sagi Grimberg 2021-07-17 6:06 ` Sagi Grimberg 2021-07-19 10:02 ` Simo Sorce 2021-07-19 10:02 ` Simo Sorce 2021-07-19 11:11 ` Hannes Reinecke 2021-07-19 11:11 ` Hannes Reinecke 2021-07-20 20:26 ` Vladislav Bolkhovitin 2021-07-20 20:26 ` Vladislav Bolkhovitin 2021-07-21 6:06 ` Hannes Reinecke 2021-07-21 6:06 ` Hannes Reinecke 2021-07-21 12:10 ` Vladislav Bolkhovitin [this message] 2021-07-21 12:10 ` Vladislav Bolkhovitin 2021-07-23 20:02 ` Vladislav Bolkhovitin 2021-07-23 20:02 ` Vladislav Bolkhovitin 2021-07-24 11:17 ` Hannes Reinecke 2021-07-24 11:17 ` Hannes Reinecke
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=833cfd62-1e1f-1dca-2e38-ff07b3a5e8fb@vlnb.net \ --to=vst@vlnb.net \ --cc=davem@davemloft.net \ --cc=hare@suse.de \ --cc=hch@lst.de \ --cc=herbert@gondor.apana.org.au \ --cc=keith.busch@wdc.com \ --cc=linux-crypto@vger.kernel.org \ --cc=linux-nvme@lists.infradead.org \ --cc=sagi@grimberg.me \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.