lkml.org 
[lkml]   [2007]   [Apr]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH resend][CRYPTO]: RSA algorithm patch
    > > 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.

    Aarghh ... just the argument I wanted to steer clear of, isn't this?
    Continuing, however, we _can_ do a lot of things in userspace, but
    still might choose to do them in the kernel, for various reasons in
    each case (performance, convenience, application transparency etc
    etc). So many things come to mind -- filesystems, readahead, the
    cryptoapi itself -- some less controversial, and some more so.

    Of course, once an infrastructure is indeed merged into the kernel, it
    better already have (or quickly develop) some users for itself. If it
    doesn't, it does end up as rot. If it does, that pretty much solves
    the maintenance problem there itself.

    Getting specific to *this* particular case, I _can_ think of other
    users in the kernel that could gladly use general asymmetric crypto
    capabilities added to the cryptoapi -- encrypting file systems, module
    signing (as of now they've just implemented DSA directly for
    themselves, not through the cryptoapi) to name a few.

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

    Well, then *all* the users of the RSA cryptoapi code would end up
    duplicating the PKCS padding for themselves! (because if we don't care
    about padding in a "low-maintenance-bare-RSA-implementation", then we
    might as well not implement any RSA crypto at all :-) Also, padding
    schemes are careful cryptographic constructions -- much like ciphers
    themselves. Much thought has gone into PKCS#1 over the years (and it's
    later revisions). We wouldn't want users to re-invent some kind of
    insecure padding for themselves.

    The way I think about this is: (1) RSA without PKCS#1 makes no sense,
    and (2) PKCS#1 is *defined* only for RSA. Combine (1) and (2), and it
    makes *all* sense to encapsulate the two in just one module.

    Coming to padding standards, RSA has been around for ~20 years now,
    and only 3 PKCS#1 padding schemes were ever defined (at least AFAICR).
    That's not something that changes so frequently as to not implement it
    in the core RSA code itself, especially when the penalties of not
    doing so could be quite embarrassing indeed.

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

    If RSA is slow, then optimizing it to make it fast (and thus have more
    impact on relative performance) should make *more* sense, shouldn't
    it? That MPI implementation is derived from GPG, which has been around
    for a decade now. I'd much rather prefer well-known and
    well-understood code that has been used, tested and maintained for a
    decade than some recent/unused contraption, thank you.

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

    Hmmm ... and again I'll excuse myself from the debate whether to
    *actually* merge MPI and asymmetric crypto capabilities into the
    mainline tree or not -- it's all about whether the potential users
    named earlier really want to be able to do all that stuff in-kernel or
    wouldn't mind writing userspace components for it.

    Cheers,
    S
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-04-12 16:23    [W:2.264 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site