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
| ||
|
Date: Sun, 24 Feb 2019 09:48:40 +0300 From: Vitaly Chikunov <vt@...linux.org> To: Herbert Xu <herbert@...dor.apana.org.au> Cc: David Howells <dhowells@...hat.com>, Mimi Zohar <zohar@...ux.vnet.ibm.com>, Dmitry Kasatkin <dmitry.kasatkin@...il.com>, linux-integrity@...r.kernel.org, keyrings@...r.kernel.org, linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [RFC PATCH 1/4] X.509: Parse public key parameters from x509 for akcipher Herbert, On Tue, Feb 19, 2019 at 12:37:32PM +0800, Herbert Xu wrote: > On Sun, Feb 10, 2019 at 09:46:28PM +0300, Vitaly Chikunov wrote: > > > > >From the other point of view, set_params may never be called or > > implemented. So, making it called first and move memory zeroing > > into set_params may create more complications than simplicity. > > > > Making both callbacks callable in any order also will not make > > things simpler. (Need to be prepared to be called in different > > order.) > > How about encoding these parameters together with the public/private > keys so that they can be set through the existing setkey functions? > > You might want to have a look at how we handle this in crypto/dh.c. Thanks. I viewed and thought about this idea. But, I think separate set_params call will be the most simple and backward compatible approach. [In the new patchset] I made set_params to be called before set_p*_key call, thus set_p*_key will know everything to start processing the key immediately. Also, I made set_params completely optional, so code that rely on RSA can just not call it, and driver that actually needs set_params may check if required parameters are set or return an error. (I overthought about zeroing of memory (in previous mail) that turned out completely non-problem as ctx in `struct crypto_akcipher' is always zeroed and I don't need to use ctx from `struct akcipher_request'). More thoughts. Parameters are part of AlgorithmIdentifier which is included in SubjectPublicKeyInfo together with subjectPublicKey. This, to pass into set_params callback AlgorithmIdentifier is the same as passing just parameters. But, passing SubjectPublicKeyInfo will overlap with passing the key into set_pub_key. So, if we pass other structure (SubjectPublicKeyInfo) into set_params we will logically conflict with set_pub_key and that call will be alternative to set_pub_key, making one of them redundant. If we pass SubjectPublicKeyInfo into set_pub_key itself (making set_params not needed) we will break ABI and compatibility with RSA drivers, because whole SubjectPublicKeyInfo is not expected by the drivers, or new set_pub_key need somehow signal to the driver that is different parameters are going (callers should be aware of that too), and/or we will need to change all RSA-centric code to use SubjectPublicKeyInfo which will affect to much code (more than verify2 required I think). And this will offload work which is already done by x509 parser into the drivers bloating their code needlessly. Thus, I think to try to remove set_params will only increase complexity. Now it's small, very flexible, and back compatible. Thanks,
Powered by blists - more mailing lists