On Thu, 30 Nov 2006, Vim Visual wrote:
> Hola, trozo de madera...
Zdravstvuj, Vimchik.
>
> > I think what you mean is to encrypt a "file system", e.g. /dev/sd0j,
> > say. (just a question of terminology). The thing made with "newfs".
> > Not the thing made with "fdisk".
>
> another problem, I realise now, is that the partition must have
> exactly the same size as the file... this is a pain, because I'd have
> to modify the script everytime
No, I don't think so. Or we misunderstand each other. The file
used for the encrypted fs only needs to be bigger. Later on this.
...
> Woodchuck, I am really starting to appreciate you a lot. Thanks for
> the comment (not joking here)
<blushes>
> As for the algorithm (this is what you ask for, right?) here you are it:
>
> mcrypt -a rijndael-256
Yikes. I'm looking at this mcrypt and not liking it. For one thing
the "time" feature is broken (at least for OpenBSD). The output
you get with --time switch. Also it is *not* a drop-in replacement
for old-tyme "crypt(1)". (To do that it should have *exactly* the
same behavior, including user prompts and other messages.) Will
tweak it some.
OK, here are some benchmarks, produced by running this script:
(as root)
#! /bin/sh
for algo in cast-128 gost rijndael-128 twofish arcfour cast-256 loki97 \
rijndael-192 saferplus wake blowfish-compat des rijndael-256 \
serpent xtea blowfish enigma rc2 tripledes
do
echo $algo 1>&2
dd if=/dev/zero bs=1000 count=100000| \
time mcrypt --time -a $algo -f /root/foo >/tmp/trash
done
This means encrypting 100 MB (yeah, I know what a MB really is,
but mcrypt doesn't). A 100 MB file /tmp/trash pre-existed the benchmarks.
mcrypt lacks the useful "null cipher", i.e. out=in, useful for benchmarking
or for losers), but I wrote one (using getchar/putchar) and it bmarks
at about 2 seconds total overhead for dd and writing to disk.
Results:
name seconds name seconds
arcfour 6 null 2
blowfish 9 wake 5
blowfish-compat 9 arcfour 6
cast-128 8 enigma 6
cast-256 11 cast-128 8
des 27 blowfish 9
enigma 6 blowfish-compat 9
gost 16 twofish 9
loki97 25 cast-256 11
null 2 gost 16
rc2 30 rijndael-128 16
rijndael-128 16 serpent 16
rijndael-192 18 rijndael-256 17
rijndael-256 17 rijndael-192 18
saferplus 74 loki97 25
serpent 16 des 27
tripledes 54 xtea 29
twofish 9 rc2 30
wake 5 tripledes 54
xtea 29 saferplus 74
I don't know how secure "wake" or "arcfour" are, but "enigma" sucks.
> :) I guess this fits your long adjective
>
> Yes, I could reduce the grade but... I am paranoid!! AREN'T YOU??
Yes, extremely. I assume anyone with the resources to crack RC4
also has a goon with a pair of pliers who can make me talk. Hence
I favor weak encryption, so as not to irritate my Masters by being
"too clever".
I did a little timing on that mcrypt, crypting a 1GB file. This
was crypting an input file of random characters to some output file.
If the two files were on the same device (a fairly speedy SCSI disk
on a well-cached controller), it was as slow as justice. "top" revealed
that the processor doing mcrypt (1GHz PIII) was only 40% utilized.
This means that most of the time is being spent doing disk operations.
I am running all this as root.
I'll do some better benchmarks after I fix mcrypts timing function
(@#$%$#). The programmer got "cute" with the output.
(See benchmarks above.)
> > I think mcrypt using a fast stream cipher may be adequate. Compared
> > to the time for zipping, it should be almost negligible.
>
> with that algorithm is totally the other way round... gzipping is a kid's play
I hope you are not married to this rijndael thing. It seems slow.
....
> it spins, it's a heavy hard disk, some 250GB and the laptop: 1.2Ghz and 1GB
> RAM
OK, this is comparable to the server I'll be running on, although
my disks are on a cached bus controller rather than USB. (A RAID
controller with raid disabled.) Maybe I'll use a different machine.
...
> I am really ruling out vnconfig... too many caveats
I have some cute ideas for vnd.
> so that I don't "forget" anything when I leave a system. In my config
> files you can find a lot of things. config_files is of course
> protected but I can't do anything against root, of course. I think I
> must cope with that.
This is why the gods made crypto and ssh. Of course, a very inquistive,
rodent-like root can corrupt the kernel and sshd sources to get
whatever he wants. But an Evil Root without skills can be fooled
by the sly user.
Well, time to do something else ;-)
Dave
--
"Confound these wretched rodents! For every one I fling away,
a dozen more vex me!" -- Doctor Doom
_______________________________________________
Openbsd-newbies mailing list
[email protected]
http://mailman.theapt.org/listinfo/openbsd-newbies
