Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC PATCH 00/11] nvme: In-band authentication support
To:     Vladislav Bolkhovitin <vst@vlnb.net>,
        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
References: <20210716110428.9727-1-hare@suse.de>
 <66b3b869-02bd-9dee-fadc-8538c6aad57a@vlnb.net>
 <e339e6e7-fc32-2480-ca99-516547105776@suse.de>
 <833cfd62-1e1f-1dca-2e38-ff07b3a5e8fb@vlnb.net>
 <2f241490-3bfd-2151-9d76-970e0d6bfd68@vlnb.net>
From:   Hannes Reinecke <hare@suse.de>
Message-ID: <d1ca46ef-4615-9385-f30b-281b6c39ac8a@suse.de>
Date:   Sat, 24 Jul 2021 13:17:35 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <2f241490-3bfd-2151-9d76-970e0d6bfd68@vlnb.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 7/23/21 10:02 PM, Vladislav Bolkhovitin wrote:
> Another comment is that better to perform CRC check of dhchap_secret and
> generation of dhchap_key right where the secret was specified (e.g.,
> nvmet_auth_set_host_key() on the target side).
> 
> No need to do it every time for every connection and by that increase
> authentication latency. As I wrote in the other comment, it might be 128
> or more connections established during connecting to a single NVMe-oF
> device.
> 
And this is something I did deliberately.
The primary issue here is that the user might want/need to change the 
PSK for re-authentication. But for that he might need to check what the 
original/current PSK is, so I think we need to keep the original PSK as 
passed in from the user.
And I found it a waste of space to store the decoded secret in addition 
to the original one, seeing that it can be derived from the original one.
But your argument about the many connections required for a single NVMe 
association is certainly true, to it would make sense to keep the decode 
one around, too, just to speed up computation.
Will be updating the patchset.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer