From: Stephan Mueller <smueller@chronox.de> 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: [PATCH 09/11] nvmet: Implement basic In-Band Authentication Date: Mon, 19 Jul 2021 10:51:53 +0200 [thread overview] Message-ID: <463a191b9896dd708015645cfc125988cd5deaef.camel@chronox.de> (raw) In-Reply-To: <59695981-9edc-6b7a-480a-94cca95a0b8c@suse.de> Am Montag, dem 19.07.2021 um 10:15 +0200 schrieb Hannes Reinecke: > On 7/18/21 2:56 PM, Stephan Müller wrote: > > Am Sonntag, 18. Juli 2021, 14:37:34 CEST schrieb Hannes Reinecke: > > > The key is also used when using the ffdhe algorithm. > > > Note: I _think_ that I need to use this key for the ffdhe algorithm, > > > because the implementation I came up with is essentially plain DH with > > > pre-defined 'p', 'q' and 'g' values. But the DH implementation also > > > requires a 'key', and for that I'm using this key here. > > > > > > It might be that I'm completely off, and don't need to use a key for our > > > DH implementation. In that case you are correct. > > > (And that's why I said I'll need a review of the FFDHE implementation). > > > But for now I'll need the key for FFDHE. > > > > Do I understand you correctly that the dhchap_key is used as the input to > > the > > DH - i.e. it is the remote public key then? It looks strange that this is > > used > > for DH but then it is changed here by hashing it together with something > > else > > to form a new dhchap_key. Maybe that is what the protocol says. But it > > sounds > > strange to me, especially when you think that dhchap_key would be, say, > > 2048 > > bits if it is truly the remote public key and then after the hashing it is > > 256 > > this dhchap_key cannot be used for FFC-DH. > > > > Or are you using the dhchap_key for two different purposes? > > > > It seems I miss something here. > > > No, not entirely. It's me who buggered it up. > I got carried away by the fact that there is a crypto_dh_encode_key() > function, and thought I need to use it here. Thank you for clarifying that. It sounds to me that there is no defined protocol (or if there, I would be wondering how the code would have worked with a different implementation). Would it make sense to first specify a protocol for authentication and have it discussed? I personally think it is a bit difficult to fully understand the protocol from the code and discuss protocol-level items based on the code. Thanks Stephan
WARNING: multiple messages have this Message-ID (diff)
From: Stephan Mueller <smueller@chronox.de> 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: [PATCH 09/11] nvmet: Implement basic In-Band Authentication Date: Mon, 19 Jul 2021 10:51:53 +0200 [thread overview] Message-ID: <463a191b9896dd708015645cfc125988cd5deaef.camel@chronox.de> (raw) In-Reply-To: <59695981-9edc-6b7a-480a-94cca95a0b8c@suse.de> Am Montag, dem 19.07.2021 um 10:15 +0200 schrieb Hannes Reinecke: > On 7/18/21 2:56 PM, Stephan Müller wrote: > > Am Sonntag, 18. Juli 2021, 14:37:34 CEST schrieb Hannes Reinecke: > > > The key is also used when using the ffdhe algorithm. > > > Note: I _think_ that I need to use this key for the ffdhe algorithm, > > > because the implementation I came up with is essentially plain DH with > > > pre-defined 'p', 'q' and 'g' values. But the DH implementation also > > > requires a 'key', and for that I'm using this key here. > > > > > > It might be that I'm completely off, and don't need to use a key for our > > > DH implementation. In that case you are correct. > > > (And that's why I said I'll need a review of the FFDHE implementation). > > > But for now I'll need the key for FFDHE. > > > > Do I understand you correctly that the dhchap_key is used as the input to > > the > > DH - i.e. it is the remote public key then? It looks strange that this is > > used > > for DH but then it is changed here by hashing it together with something > > else > > to form a new dhchap_key. Maybe that is what the protocol says. But it > > sounds > > strange to me, especially when you think that dhchap_key would be, say, > > 2048 > > bits if it is truly the remote public key and then after the hashing it is > > 256 > > this dhchap_key cannot be used for FFC-DH. > > > > Or are you using the dhchap_key for two different purposes? > > > > It seems I miss something here. > > > No, not entirely. It's me who buggered it up. > I got carried away by the fact that there is a crypto_dh_encode_key() > function, and thought I need to use it here. Thank you for clarifying that. It sounds to me that there is no defined protocol (or if there, I would be wondering how the code would have worked with a different implementation). Would it make sense to first specify a protocol for authentication and have it discussed? I personally think it is a bit difficult to fully understand the protocol from the code and discuss protocol-level items based on the code. Thanks Stephan _______________________________________________ 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-19 8:57 UTC|newest] Thread overview: 163+ 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 [this message] 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 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 2022-03-23 7:12 [PATCHv9 " Hannes Reinecke 2022-03-23 7:13 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2022-03-28 8:08 [PATCHv10 00/11] nvme: In-band authentication support Hannes Reinecke 2022-03-28 8:08 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2022-03-28 13:39 [PATCHv11 00/11] nvme: In-band authentication support Hannes Reinecke 2022-03-28 13:39 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2022-05-18 11:22 [PATCHv12 00/11] nvme: In-band authentication support Hannes Reinecke 2022-05-18 11:22 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2022-05-22 11:44 ` Max Gurtovoy 2022-05-23 6:03 ` Hannes Reinecke 2022-05-25 10:42 ` Sagi Grimberg 2022-06-07 10:46 ` Christoph Hellwig 2022-06-08 14:45 [PATCHv14 00/11] nvme: In-band authentication support Hannes Reinecke 2022-06-08 14:45 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2022-06-21 9:02 [PATCHv15 00/11] nvme: In-band authentication support Hannes Reinecke 2022-06-21 9:02 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2022-06-21 17:24 [PATCHv16 00/11] nvme: In-band authentication support Hannes Reinecke 2022-06-21 17:24 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2022-06-23 6:17 [PATCHv17 00/11] nvme: In-band authentication support Hannes Reinecke 2022-06-23 6:17 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication Hannes Reinecke 2022-06-27 9:51 [PATCHv18 00/11] nvme: In-band authentication support Hannes Reinecke 2022-06-27 9:52 ` [PATCH 09/11] nvmet: Implement basic In-Band Authentication 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=463a191b9896dd708015645cfc125988cd5deaef.camel@chronox.de \ --to=smueller@chronox.de \ --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.