On Thu, April 12, 2007 11:35, Satyam Sharma wrote: > Firstly, I'd like to steer clear of all the RSA-in-kernel-or-userspace > / MPI-in-kernel-or-userspace arguments. True, MPI / RSA / (PKI? that > even requires some knowledge of ASN.1 etc to parse certificates) do > add a lot of bloat to the kernel. That said, I don't see any other > reason to _not_ do asymmetric crypto in the kernel either. In some > situations, that in fact simplifies the overall system by avoiding the > use of additional userspace components / daemons to do the key > management stuff.
Because it can all be done in userspace? Can trap all binary loading from user-space too, though that must be done carefully, without changing the kernel. > 1. First, sorry, I don't think an RSA implementation not conforming to > PKCS #1 qualifies to be called RSA at all. That is definitely a *must* > -- why break strong crypto algorithms such as RSA by implementing them > in insecure ways? It's still RSA, that it's not enough to get a complete and secure crypto system doesn't mean it isn't RSA anymore. Maybe you're right and having RSA without the rest makes no sense. But things like padding schemes change, the core RSA algorithm does't, so I think when adding anything that's unused by the rest of the kernel it has more chance if it's a low maintenance bare RSA implementation. > 3. Please, try to re-use the MPI library from GnuPG that has already > been ported to the kernel -- not the mainline tree, but most > distributions such as Red Hat, Fedora, Debian, Suse(?) have maintained > an MPI library in crypto/ for the modsign stuff for years now -- that > would make your entire RSA module merely a set of wrappers > (implementing PKCS#1) to the core modular exponentiation functions in > that MPI library. It also contains implementations of optimized > algorithms for a lot of the mathematics involved, so you have only to > benefit from utilizing a library that has been used, maintained and > tested for years. Right, and that MPI implementation isn't merged. Perhaps a smaller, simpler, not complexified by optimisations version has more chance. RSA is damn slow anyway, so better to concentrate on other things than speed, IMHO. That said, perhaps the different groups could concentrate on one implementation they all agree on? That's the main advantage of having it mainline, that there's a common place to cencentrate all effort into. But keep in mind that it's a precaurious balance, at least that's how I see it. Right now it's about a rather static 800 lines of code which implements some common algorithms. Not much bloat, low maintenance, over all not much reason to not merge it, except that it isn't used by the rest of the kernel. If you're going to add the full kitchen sink, it might not look that appealing anymore, and merging it will become much harder, especially as no one provided good arguments why it can't be done in user space. Perhaps, with that in mind, it's better to not merge the bare RSA version either, as it might give false hope for more, because it looks like most implementations should be done in user space (either because that's better anyway, or because of legal reasons). Greetings, Indan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
