netdev - RE: [crypto 6/8] chtls: TCB and Key program

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 7 Dec 2017 15:08:04 +0000
From:   Atul Gupta <atul.gupta@...lsio.com>
To:     Stephan Mueller <smueller@...onox.de>
CC:     "herbert@...dor.apana.org.au" <herbert@...dor.apana.org.au>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "davejwatson@...com" <davejwatson@...com>,
        Ganesh GR <ganeshgr@...lsio.com>,
        "Harsh Jain" <Harsh@...lsio.com>
Subject: RE: [crypto 6/8] chtls: TCB and Key program



-----Original Message-----
From: linux-crypto-owner@...r.kernel.org [mailto:linux-crypto-owner@...r.kernel.org] On Behalf Of Stephan Mueller
Sent: Thursday, December 7, 2017 8:13 PM
To: Atul Gupta <atul.gupta@...lsio.com>
Cc: herbert@...dor.apana.org.au; linux-crypto@...r.kernel.org; netdev@...r.kernel.org; davem@...emloft.net; davejwatson@...com; Ganesh GR <ganeshgr@...lsio.com>; Harsh Jain <Harsh@...lsio.com>
Subject: Re: [crypto 6/8] chtls: TCB and Key program

Am Donnerstag, 7. Dezember 2017, 15:21:03 CET schrieb Atul Gupta:

Hi Atul,

> 
> memzero_explicit(key)?
> [Atul] may not be required as entire info of size keylen and 
> AEAD_H_SIZE is copied onto kctx->key. Key data is received from user, 
> while ghash is memset and locally generated

Sure, but wouldn't it make sense to zap all instances where key material was stored?
Agree, Its safe to memset where keylen is variable, perhaps in future where we support different keylen. In current case key len is same as buffer size hence may not cause issue. 

> 
> As far as I see, the key is part of the skb (via kctx). This skb is 
> released after being processed. The release calls kfree_skb which does 
> not zeroize the key. Wouldn't it make sense to clear the memory of the 
> key when the skb is released? [Atul] we should perhaps memset the info 
> received from user so that driver has no info on key once its written on chip memory.
> memset(gcm_ctx->key, 0, keylen);

Are you saying that the skb (via kctx) above does not obtain a copy of the key? If not, what is done in chtls_key_info?
It does have a key copy, I was not sure how key info is accessed once skb is released.


Ciao
Stephan

Thanks
Atul