From: Stephan Mueller <smueller@chronox.de>
To: Tudor-Dan Ambarus <tudor-dan.ambarus@nxp.com>
Cc: "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"tadeusz.struk@intel.com" <tadeusz.struk@intel.com>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
Horia Ioan Geanta Neag <horia.geanta@nxp.com>
Subject: Re: [PATCH 02/10] crypto: rsa_helper - add raw integer parser actions
Date: Mon, 21 Mar 2016 20:14 +0100 [thread overview]
Message-ID: <2101032.u08j97mEB2@tauon.atsec.com> (raw)
In-Reply-To: <AM3PR04MB13004732D24525234255CB72B88F0@AM3PR04MB1300.eurprd04.prod.outlook.com>
Am Montag, 21. März 2016, 15:17:20 schrieb Tudor-Dan Ambarus:
Hi Tudor,
> Hi Stephan,
>
> > -----Original Message-----
> > From: Stephan Mueller [mailto:smueller@chronox.de]
> > Sent: Friday, March 18, 2016 9:47 PM
> > To: Tudor-Dan Ambarus
> > Cc: herbert@gondor.apana.org.au; tadeusz.struk@intel.com; linux-
> > crypto@vger.kernel.org; Horia Ioan Geanta Neag
> > Subject: Re: [PATCH 02/10] crypto: rsa_helper - add raw integer parser
> > actions
> >
> > > +int rsa_check_key_length(unsigned int len)
> > > +{
> > > + switch (len) {
> > > + case 512:
> > > + case 1024:
> > > + case 1536:
> > > + case 2048:
> > > + case 3072:
> > > + case 4096:
> > > + return 0;
> > > + }
> >
> > I know that you copied the code to a new location that was there already.
> > But
> > based on the discussion we had for DH, does it make sense that the kernel
> > adds
> > such (artificial) limits?
>
> [ta] This is not within the scope of this patch set, but we can remove the
> restrictions in a subsequent patch. Marcel has suggested to not impose
> limits on the minimum length of the key. What about the maximum?
Why any restrictions at all? There is no mathematical reason. There is only a
technical reason which depends on the implementation.
I am not sure how large the keys can be for the software fallback. But maybe
it would make sense to have a general cap like 32k where the software fallback
can handle all key sizes up to that point.
> > > +
> > > + return -EINVAL;
> > > +}
> > > +EXPORT_SYMBOL_GPL(rsa_check_key_length);
> > > +
> > > +int raw_rsa_get_n(void *context, size_t hdrlen, unsigned char tag,
> > > + const void *value, size_t vlen)
> > > +{
> > > + struct rsa_raw_ctx *ctx = context;
> > > + struct rsa_raw_key *key = &ctx->key;
> > > + const char *ptr = value;
> > > + int ret = -EINVAL;
> > > +
> > > + while (!*ptr && vlen) {
> > > + ptr++;
> > > + vlen--;
> > > + }
> > > +
> > > + key->n_sz = vlen;
> > > + /* In FIPS mode only allow key size 2K & 3K */
> > > + if (fips_enabled && (key->n_sz != 256 && key->n_sz != 384)) {
> >
> > Again, you copied that code that used to be there . But very very
> > recently,
> > NIST allowed 4k keys too. May I ask to allow it here?
>
> I suggest to do this in a separate patch. Can you send us a pointer to the
> NIST specification?
Sure, just let us not forget about it.
>
> Thank you,
> ta
Ciao
Stephan
next prev parent reply other threads:[~2016-03-21 19:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-18 18:31 [PATCH 01/10] crypto: rsa - generalize ASN.1 sequences Tudor Ambarus
2016-03-18 18:31 ` [PATCH 02/10] crypto: rsa_helper - add raw integer parser actions Tudor Ambarus
2016-03-18 19:46 ` Stephan Mueller
2016-03-21 15:17 ` Tudor-Dan Ambarus
2016-03-21 19:14 ` Stephan Mueller [this message]
2016-03-18 18:32 ` [PATCH 03/10] crypto: add CONFIG_ symbol for rsa helper Tudor Ambarus
2016-03-18 18:32 ` [PATCH 04/10] crypto: rsa_helper - export symbols for asn1 structures Tudor Ambarus
2016-03-18 18:32 ` [PATCH 05/10] crypto: qat - avoid memory corruption or undefined behaviour Tudor Ambarus
2016-03-18 18:32 ` [PATCH 06/10] crypto: qat - fix address leaking of RSA public exponent Tudor Ambarus
2016-03-18 18:32 ` [PATCH 07/10] crypto: qat - remove duplicate ASN.1 parser Tudor Ambarus
2016-03-20 14:55 ` Tadeusz Struk
2016-03-21 10:12 ` Tudor-Dan Ambarus
2016-03-18 18:32 ` [PATCH 08/10] crypto: scatterwak - Add scatterwalk_sg_copychunks Tudor Ambarus
2016-03-18 19:52 ` Stephan Mueller
2016-03-18 18:32 ` [PATCH 09/10] crypto: scatterwalk - export scatterwalk_pagedone Tudor Ambarus
2016-03-18 18:32 ` [PATCH 10/10] crypto: caam - add support for RSA algorithm Tudor Ambarus
2016-03-19 16:59 ` Stephan Mueller
2016-03-21 11:07 ` Tudor-Dan Ambarus
2016-03-20 14:53 ` [PATCH 01/10] crypto: rsa - generalize ASN.1 sequences Tadeusz Struk
2016-03-21 10:11 ` Tudor-Dan Ambarus
2016-03-21 15:24 ` Tadeusz Struk
Reply instructions:
You may reply publicly 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=2101032.u08j97mEB2@tauon.atsec.com \
--to=smueller@chronox.de \
--cc=herbert@gondor.apana.org.au \
--cc=horia.geanta@nxp.com \
--cc=linux-crypto@vger.kernel.org \
--cc=tadeusz.struk@intel.com \
--cc=tudor-dan.ambarus@nxp.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.