Linux-Integrity Archive on lore.kernel.org
 help / color / Atom feed
From: Vitaly Chikunov <vt@altlinux.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David Howells <dhowells@redhat.com>,
	Mimi Zohar <zohar@linux.vnet.ibm.com>,
	Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 1/4] X.509: Parse public key parameters from x509 for akcipher
Date: Sun, 24 Feb 2019 09:48:40 +0300
Message-ID: <20190224064840.hii4ccjksjdnewae@altlinux.org> (raw)
In-Reply-To: <20190219043732.x3sbwzqlz4ikntxo@gondor.apana.org.au>

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,


  reply index

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-06 13:36 [RFC PATCH 0/4] crypto: Add EC-RDSA algorithm Vitaly Chikunov
2019-01-06 13:36 ` [RFC PATCH 1/4] X.509: Parse public key parameters from x509 for akcipher Vitaly Chikunov
2019-02-09 21:42   ` Vitaly Chikunov
2019-02-10 18:46     ` Vitaly Chikunov
2019-02-19  4:37       ` Herbert Xu
2019-02-24  6:48         ` Vitaly Chikunov [this message]
2019-02-28  6:14           ` Herbert Xu
2019-02-28  7:04             ` Vitaly Chikunov
2019-02-28  7:11               ` Vitaly Chikunov
2019-02-28  7:51               ` Herbert Xu
2019-02-28  8:28                 ` Vitaly Chikunov
2019-02-28  9:01                   ` Herbert Xu
2019-02-28 10:33                     ` Vitaly Chikunov
2019-02-28 10:37                       ` Herbert Xu
2019-03-01 16:06                         ` Vitaly Chikunov
2019-01-06 13:36 ` [RFC PATCH 2/4] akcipher: Introduce verify2 for public key algorithms Vitaly Chikunov
2019-01-06 13:36 ` [RFC PATCH 3/4] KEYS: set correct flags for keyctl if encrypt is not supported Vitaly Chikunov
2019-01-06 13:36 ` [RFC PATCH 4/4] crypto: Add EC-RDSA algorithm Vitaly Chikunov
2019-01-06 18:11   ` Stephan Müller
2019-01-07  8:07     ` Vitaly Chikunov
2019-01-07  8:31       ` Stephan Mueller
2019-01-07  9:04         ` Vitaly Chikunov
2019-01-16 16:15         ` David Howells
2019-01-16 16:19 ` [RFC PATCH 2/4] akcipher: Introduce verify2 for public key algorithms David Howells

Reply instructions:

You may reply publically 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=20190224064840.hii4ccjksjdnewae@altlinux.org \
    --to=vt@altlinux.org \
    --cc=dhowells@redhat.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zohar@linux.vnet.ibm.com \
    /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: link

Linux-Integrity Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-integrity/0 linux-integrity/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-integrity linux-integrity/ https://lore.kernel.org/linux-integrity \
		linux-integrity@vger.kernel.org linux-integrity@archiver.kernel.org
	public-inbox-index linux-integrity


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-integrity


AGPL code for this site: git clone https://public-inbox.org/ public-inbox