lkml.org 
[lkml]   [2019]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC PATCH 4/4] crypto: Add EC-RDSA algorithm
Date
Am Montag, 7. Januar 2019, 09:07:10 CET schrieb Vitaly Chikunov:

Hi Vitaly,

> > 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). 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.

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,
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


\
 
 \ /
  Last update: 2019-01-07 09:33    [W:0.108 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site