On Thu, Oct 05, 2000 at 01:06:01PM -0400, Sandy Harris wrote:
> Marc Mutz wrote:
> > I thought that Pk encryption was only used for key exchange. That could
> > happily live in userspace.
>
> Yes, for IPSEC. But if you want the kernel to authenticate binaries before
> loading them, then you may need public key stuff in the kernel.
>
Until someone can show that this is needed, I do not see the point in
having the kernel authenticate binaries. We have a file-system, and
if we accept that the file-system is secure, we can put the public-key
crypto in the tools that are given the privilege of introducing a new
executable program in the file-system.
If you say that we can not trust the file-system, then I say that you
can encrypt the file-system. Then you are back to the point where you
have a user-level tool that does the public-key crypto when you mount
the file-system.
Even if you want to authenticate binaries, you can register
"authorities" with the kernel so that the kernel only authenticates
binaries with a HMAC. You can _still_ have a user-level tool that
introduces those authorities into the kernel and does the necessary
public-key crypto. I have a hard time imagining a system where:
- There is _a lot_ of users able to introduce new binaries in the
system so that registering them all in the kernel is awkward.
- For some weird reason, you can not trust the filesystem.
- There is no user-land workaround.
All in all, I still do not understand why public-key crypto should be
used in the kernel. I do not see a place for it until there comes an
application where there are big _performance_ advantages of having it
there. Few such applications exists because one generally tries to
keep public-key crypto out of performance-critical areas.
astor
--
Alexander Kjeldaas Mail: astor@xxxxxxx
finger astor@xxxxxxxxxxxxxxxxx for OpenPGP key.
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
