On Thu, 30 Nov 2006, Vim Visual wrote:
> Hi,
>
> reading man vnconfig(8) I guess it'd be easy to associate an
> encryption key with a vnode... but this way I create an encrypted disk
> partition image... it's not like having the partition itself in the
> disk and, what's more, I am thinking of some ~6 GB, which is huge, so
> that I think this is not the way to do it.
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".
> Is there any alternative? Let me describe what I am looking for:
>
> I work at an Institute and I was given a usb disk. As I have my laptop
> almost always with me and use it to do all my work (almost, I am using
> a cluster somewhere else, but the data analysis, etc is done here, I
Sounds like CERN ;-)
....
> usbdisk comes in play:
>
> When I am in my office I would like to just plug the usbdisk and run a
> small backup script to copy over the most important things; still this
> is some 6 GB; I could not reduce it more. When I go home, the disk
> stays here and you therefore would just have to plug in a cable to
> read/delete/copy everything you want.
>
> That's why I need encryption. I was using a time ago mcrypt to encrypt
> the file itself, which is nice but it'd take some 1-2 hours to encrypt
> everything and then I would just forget about backup (you know, the
> best backup is the one you do in an easy, quick way; otherwise you
> become lazy and forget it)
Yeah. What the world needs (among other things) is "tarcrypt", a
version of tar that would, after passing the data through gzip,
would then pass it through a filter of the user's specification,
that is, some sort of stream cipher. This is not hard to do as a
programming task. But the same effect can be had in a script with
no speed penalty. (So modifying tar is therefore silly, but a good
exercise for a Unix student in use of pipes and process control).
tar -cpf - /home/foo | gzip -c | cryptfilter > /mnt/foo.tar.gz.cr
There is probably a way to script a file-> file copy, too, without
gzip, but that would require more thought. Directory names are
harder to encrypt. (But the sly programmer can do this, too).
Directory *structure* is even harder to obscure on a file by file
encryption scheme.
> Any suggestions?
The tar pipe is portable, as portable as "cryptfilter" (ficticious
program name, presumably mcrypt). Is vnconfig encrypted file system
portable? To Linux? since this is "somebody else's" data, they
should be able to decrypt it on their machines (I'm guessing), and
should have the key if you get hit by a bus or something. If they're
all running windoze or Linux or whatever, I suspect that a vnconfig
encrypted file system will resist their every effort. It may even
be harder for them to figure out vnconfig than to crack the cipher
(joking here).
Also your long encrypt time interests me. I think it's way too
long, unless you are in need of some sort of long-term
military-government-criminal (three near synonyms) grade of encryption.
If you need that grade of encryption, then you also need a shielded
laptop, and probably should never move the data outside a Faraday
cage. It sounds like a "nuisance" cipher might be adequate. Does
the data's owner have a standard?
I think mcrypt using a fast stream cipher may be adequate. Compared
to the time for zipping, it should be almost negligible.
I've never fussed around with vnconfig, but am willing to give it
a try tonight.
Is the USB disk a "flash" ("thumb") drive or the kind that spins
around? How fast is the laptop?
Notes on vnconfig... the "K" option is poorly documented.
The minimum numbre of passes is 1000, and the salt file needs
to be 128bytes. You can let it create a salt file by giving
it the name of a file that does not exist. It will fill it with
(pseudo?) randomness. Keep the salt file handy.
vnconfig may be all you need. -- except for the portability
issue.
> BTW a funny story:
> ==============
:-)
This is an old story, found on every system that tries to make it
possible to "undelete" files. We see the "teeth" in this trap here
fully bared and sinking into the admin's neck. He's a very lucky
fellow. Moral: it is BAD to implement undelete this way. (Better
is "file versions" as on VMS, while editing foo.bar.1 created, when
done foo.bar.2, leaving foo.bar.1 alone. But it still was a problem).
Further Moral: creating invisible (i.e. .name) files in a user's
directory is always bad, some kind of security risk. Configuration
directories are bad enough. Big Moral: User-friendliness has
drawbacks. Better is user-cluefulness.
Show the admin how to properly wipe a disk.
(dd if=/dev/zero of=/dev/rsdxxx) is probably enough for casual use.)
Dave
_______________________________________________
Openbsd-newbies mailing list
[email protected]
http://mailman.theapt.org/listinfo/openbsd-newbies
