Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:20:35 ADT
Anonymous (nobody@replay.com)
Sat, 18 Jul 1998 00:00:31 +0200
On Thu, 16 Jul 1998, Oskar Pearson wrote:
> Hi All
>
> I am new to this list. From the discussion I have seen this appears to be
> fairly theorectical, but I hope that this mail is on topic. Please tell
> me to stay way if it's not.
>
> I am planning on making the linux-kernel cryptography stuff easy to use
> and secure. Currently the stuff that comes with the kernel is messed (see
> the mail below).
>
> The patches will mostly be based on the berkeley ones, but since SA doesn't
> have any crypto laws I am going to host them here. The berkeley ones
> haven't seen much change for a long time (since 2.0.11).
Andrew Mileski has a rather good set of patches. Unfortunately, the latest
alpha versions have a bug which causes the disk driver layer to die when a
loopback device which is pointing to a floppy is "losetup -d." He also
doesn't have the time to update them, so the latest version is usually far
behind. In this case, it's 2.1.98.
> The linux-kernel people don't seem to have a crypto background - since
> Solar Designer's mail went completely unanswered...
It won't be integrated into the kernel or the system utilities due to
export restrictions. It will have to be distributed as an independent
patch set and set of utilities.
> 3) Has anyone got a Gnu assembler version of twofish? I know absolutely
> no assembler, but I would like to put twofish (in optimized
> form) into the kernel... Anyone think this is a bad idea? (Bruce - you
> aren't allowed to comment, ok? :)
I'd say go ahead and stick in as many cyphers as possible. Put in DES,
IDEA, 3DES, Twofish, Blowfish, CAST-128, and others. Let the user decide
how to stack them up. Warn users of cyphers like Twofish that the cypher
is new. In fact, including descriptions and strength/weakness lists for
each of the cyphers is probably a good idea.
Since you're volunteering, I'll hit you with a combination wish and caveat
list. Of course, these also turn this into a mammoth project, so it's just
wishful thinking. :) Most of these are simpler than they sound, probably
with the exception of #2 and #8:
1) Don't integrate this into ext2. Make a separate filesystem type. Maybe
it can use the ext2 code, but don't actually integrate it into ext2 unless
you can ensure that it won't break anything if non-patched filesystem code
is run on the filesystem. This is important. There exist compressed
filesystem patches out there which do (or did) cause fsck to completely
hose the filesystem if a non-patched kernel was run on a filesystem with
compressed files.
2) Allow a variety of key schemes. Maybe the user wants to use a keydisk.
Maybe the user wants to keep the keys in a file on the drive, and then
keep that file encrypted with a keydisk. Maybe the user wants to keep an
encrypted keydisk around and require that.
3) Allow for a "panic key." If the ninjas come through your windows, you
hit the key and it emergency unmounts the filesystems then starts wiping
the keys. Make sure this is secure.
4) Set something up for easier super-encryption. Maybe I want to set up a
partition which is encrypted with IDEA, then CAST, then Blowfish, then
Twofish. This is currently possible with AEM's loop driver by chaining
loop devices together.
5) While you're hacking away, set up a way to securely wipe a disk file
using data from the user's choice of /dev/urandom or /dev/random.
(/dev/random is more secure but is much slower.)
6) Write a little console administration utility. The user should be able
to play with key-disks, mount and unmount filesystems, change keys easily
(important!), wipe specific encrypted filesystems, etc. This will go a
long way towards getting more people to use it.
7) Make sure support is there for encrypted swap. AEM's loop driver
currently allows this. (Mount the swap partition or swap file as a loop
device and set the encryption there. Then run mkswap and swapon on it. The
key can be complete garbage since once the partition is unmounted you
don't need it anymore.)
8) Come up with an easy way to let somebody encrypt existing filesystems.
If somebody wants to encrypt their root FS and are willing to take
whatever performance hit their cypher gives them, they should be able to.
Something like Twofish probably wouldn't be too bad.
Unfortunately, the only way I can think of implementing #8 and protect
against software tampering is an encrypted floppy with the kernel on it.
You stick it in the drive and boot it. A small bit of code asks for the
passphrase. You type it in. It decrypts the kernel. The kernel gets
control, burns the previous code, and boots. When it needs to mount the
filesystems, it discovers they're encrypted. It asks for another
passphrase.
For reference, we wouldn't want to have *only* a usermode utility to set
up the root filesystem algorithms and stuff. That would mean that if
something happened the user wouldn't be able to recover, since he wouldn't
be able to access the utility. The usermode utility I mentioned in #6
should really handle this too, but there *HAS* to be a way to configure
this during the actual kernel boot, maybe by having the user hit the SysRq
key at that prompt or something.
A person could sidestep this requirement and keep a set of hashes for the
files, but that's much slower and is screwed up the first time you update
the files.
Now, all this stuff would really be nice, but I don't have time to code
it. I doubt anybody else does either. I know that's a tired old refrain,
but does anybody actually have the time to code all this stuff?
Reasons:
1) I explained that.
2) Enhanced security. If somebody is chasing you, you dispose of the disk.
The data on your drive is now useless.
3) Self-explanatory.
4) I would think that would seriously frustrate brute force efforts. I
could be wrong. I'm not a real crypto expert.
5) You always hear about people who delete files on their machine but are
too inept to wipe them. I don't know how ext2 handles it, but on some
machines 'pgp -w' may not work. It'd be preferable to have this in the FS
code. I think BSD does this.
6) A utility like that is needed to get people to use this stuff. The more
people who use it and use it correctly, the less suspicious using it
correctly makes you look. Even an experienced programmer would start to
want a utility like that after a while. This also has the advantage of
maybe abstracting this from losetup, mount, and those other utilities
which are updated by distribution maintainers all the time.
7) That's important. If you're storing the data on an encrypted filesystem
but it's being periodically swapped out, your security is useless.
8) It's really important to protect against software tampering. Your
security is worthless if somebody can come into your office, pull out your
drive, replace your utilities with their own versions, put it back, and
come back later to get your passphrases or pick them up over the net. If
it's done right, there are so many software backdoors in your system that
you'll never get them out with anything short of a complete reinstall of
all your binaries and your OS.
Then again, if the spooks are that interested in you they could spike the
package maintainers' versions and get you anyway. This would still protect
against Joe Random Idiot, though.
The following archive was created by hippie-mail 7.98617-22 on Fri Aug 21 1998 - 17:20:35 ADT