[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <776.1323085419@redhat.com>
Date: Mon, 05 Dec 2011 11:43:39 +0000
From: David Howells <dhowells@...hat.com>
To: "H. Peter Anvin" <h.peter.anvin@...el.com>
Cc: dhowells@...hat.com, keyrings@...ux-nfs.org,
linux-crypto@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-kernel@...r.kernel.org, dmitry.kasatkin@...el.com,
zohar@...ux.vnet.ibm.com, arjan.van.de.ven@...el.com,
alan.cox@...el.com
Subject: Re: [RFC][PATCH 00/16] Crypto keys and module signing [ver #2]
H. Peter Anvin <h.peter.anvin@...el.com> wrote:
> Do we really need the complexity of a full OpenPGP parser? Parsers are
> notorious security problems.
Actually, I don't have a full PGP parser. I only handle the minimum I need.
It can parse the packet stream, public key packets and signature packets.
That's it. I cannot guarantee that GPG is always going to put packets in the
stream in the same order, and dealing with the possible variation should be
simple enough.
Note that it might be possible to share the parser with other things like
eCryptFS.
> Furthermore, using DSA in anything but a hard legacy application is not
> something you want to encourage, so why support DSA?
Because DSA is what Red Hat currently uses in its module signing. So the first
thing to do was to get that working again and then work on getting RSA working.
If I just jumped straight into the RSA parser, I would have a lot more stuff
that might be wrong; doing DSA first at least validated the common stuff.
However, we don't have to include the DSA stuff in the kernel; I can always
discard that patch from the upstream-aimed patchset.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists