All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Chikunov <vt@altlinux.org>
To: Stephan Mueller <smueller@chronox.de>
Cc: David Howells <dhowells@redhat.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	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 4/4] crypto: Add EC-RDSA algorithm
Date: Mon, 7 Jan 2019 12:04:49 +0300	[thread overview]
Message-ID: <20190107090449.d364ii24zervlsfq@sole.flsd.net> (raw)
In-Reply-To: <1714084.mfT8VG1pOj@tauon.chronox.de>

Stephan,

On Mon, Jan 07, 2019 at 09:31:40AM +0100, Stephan Mueller wrote:
> Am Montag, 7. Januar 2019, 09:07:10 CET schrieb Vitaly Chikunov:
> 
> > > Why do you manually parse the ASN.1 structure instead of using the ASN.1
> > > parser?
> > 
> > I am not sure this worth effort and will not be most degenerate use of
> > asn1_ber_decoder, since 1) I only need to parse one type in each case:
> > OCTET STRING string above code, and OIDs in below code; 2) this data is
> > said to be in DER format, which asn1_ber_decoder can not enforce. Surely
> > this will also produce more code and files.
> 
> RSA public keys also only contain n and e in the ASN.1 structure for which the 
> ASN.1 parser is used (see linux/crypto/rsapubkey.asn1).

Yes I saw it, but at least there is two values (n and e), while EC-RDSA
pub_key is just one OCTET STRING value (which internally is not defined
to be ASN.1).

> As ASN.1 parsing is always having security issues, I would rather suggest to
> have this parsing implemented in one spot and not here and there.

Yes. So I tried to parse it very carefully and strictly.

> Regarding your comment (2), I am not sure I understand. Why do you say that 
> the DER format cannot be parsed by the kernel's ASN.1 parser? For example, 

It can, but DER is stricter than BER. For example, in DER 'OCTET STRING'
length field should be encoded in just one byte if it's smaller than
128, in BER it could be encoded in multiple encodings. This does not
seem like a big deal, though. With BER decoder an improperly DER-encoded
certificate could be successfully parsed.

> when you generate RSA keys in DER format with, say, openssl, the kernel ASN.1 
> parser will happily use them. Also, when I created my (not accepted) patch to 
> load PQG domain parameters for DH using the ASN.1 parser, the PQG domain 
> parameters created by openssl in DER format were processed well.
> 
> Ciao
> Stephan
> 

WARNING: multiple messages have this Message-ID (diff)
From: Vitaly Chikunov <vt@altlinux.org>
To: Stephan Mueller <smueller@chronox.de>
Cc: David Howells <dhowells@redhat.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	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 4/4] crypto: Add EC-RDSA algorithm
Date: Mon, 07 Jan 2019 09:04:49 +0000	[thread overview]
Message-ID: <20190107090449.d364ii24zervlsfq@sole.flsd.net> (raw)
In-Reply-To: <1714084.mfT8VG1pOj@tauon.chronox.de>

Stephan,

On Mon, Jan 07, 2019 at 09:31:40AM +0100, Stephan Mueller wrote:
> Am Montag, 7. Januar 2019, 09:07:10 CET schrieb Vitaly Chikunov:
> 
> > > Why do you manually parse the ASN.1 structure instead of using the ASN.1
> > > parser?
> > 
> > I am not sure this worth effort and will not be most degenerate use of
> > asn1_ber_decoder, since 1) I only need to parse one type in each case:
> > OCTET STRING string above code, and OIDs in below code; 2) this data is
> > said to be in DER format, which asn1_ber_decoder can not enforce. Surely
> > this will also produce more code and files.
> 
> RSA public keys also only contain n and e in the ASN.1 structure for which the 
> ASN.1 parser is used (see linux/crypto/rsapubkey.asn1).

Yes I saw it, but at least there is two values (n and e), while EC-RDSA
pub_key is just one OCTET STRING value (which internally is not defined
to be ASN.1).

> As ASN.1 parsing is always having security issues, I would rather suggest to
> have this parsing implemented in one spot and not here and there.

Yes. So I tried to parse it very carefully and strictly.

> Regarding your comment (2), I am not sure I understand. Why do you say that 
> the DER format cannot be parsed by the kernel's ASN.1 parser? For example, 

It can, but DER is stricter than BER. For example, in DER 'OCTET STRING'
length field should be encoded in just one byte if it's smaller than
128, in BER it could be encoded in multiple encodings. This does not
seem like a big deal, though. With BER decoder an improperly DER-encoded
certificate could be successfully parsed.

> when you generate RSA keys in DER format with, say, openssl, the kernel ASN.1 
> parser will happily use them. Also, when I created my (not accepted) patch to 
> load PQG domain parameters for DH using the ASN.1 parser, the PQG domain 
> parameters created by openssl in DER format were processed well.
> 
> Ciao
> Stephan
> 

  reply	other threads:[~2019-01-07  9:04 UTC|newest]

Thread overview: 46+ 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 ` Vitaly Chikunov
2019-01-06 13:36 ` [RFC PATCH 1/4] X.509: Parse public key parameters from x509 for akcipher Vitaly Chikunov
2019-01-06 13:36   ` Vitaly Chikunov
2019-02-09 21:42   ` Vitaly Chikunov
2019-02-09 21:42     ` Vitaly Chikunov
2019-02-10 18:46     ` Vitaly Chikunov
2019-02-10 18:46       ` Vitaly Chikunov
2019-02-19  4:37       ` Herbert Xu
2019-02-19  4:37         ` Herbert Xu
2019-02-24  6:48         ` Vitaly Chikunov
2019-02-24  6:48           ` Vitaly Chikunov
2019-02-28  6:14           ` Herbert Xu
2019-02-28  6:14             ` Herbert Xu
2019-02-28  7:04             ` Vitaly Chikunov
2019-02-28  7:04               ` Vitaly Chikunov
2019-02-28  7:11               ` Vitaly Chikunov
2019-02-28  7:11                 ` Vitaly Chikunov
2019-02-28  7:51               ` Herbert Xu
2019-02-28  7:51                 ` Herbert Xu
2019-02-28  8:28                 ` Vitaly Chikunov
2019-02-28  8:28                   ` Vitaly Chikunov
2019-02-28  9:01                   ` Herbert Xu
2019-02-28  9:01                     ` Herbert Xu
2019-02-28 10:33                     ` Vitaly Chikunov
2019-02-28 10:33                       ` Vitaly Chikunov
2019-02-28 10:37                       ` Herbert Xu
2019-02-28 10:37                         ` Herbert Xu
2019-03-01 16:06                         ` Vitaly Chikunov
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   ` 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   ` Vitaly Chikunov
2019-01-06 13:36 ` [RFC PATCH 4/4] crypto: Add EC-RDSA algorithm Vitaly Chikunov
2019-01-06 13:36   ` Vitaly Chikunov
2019-01-06 18:11   ` Stephan Müller
2019-01-06 18:11     ` Stephan Müller
2019-01-07  8:07     ` Vitaly Chikunov
2019-01-07  8:07       ` Vitaly Chikunov
2019-01-07  8:31       ` Stephan Mueller
2019-01-07  8:31         ` Stephan Mueller
2019-01-07  9:04         ` Vitaly Chikunov [this message]
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 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=20190107090449.d364ii24zervlsfq@sole.flsd.net \
    --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=smueller@chronox.de \
    --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
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.