lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ