I have a quite common encryption scenario:
Where I work, we (the tech-team) need to backup the company's mission-critical
data periodically and use cheap cdrom as backup media. Until recently we
simply fired the data onto the cdrs, now we'd like to encrypt the data so no
one (esp. competitors) could read our backups.
Why not pipe the archives through gpg or something like that? Yes we could do
that.
But the crypto-loop functions on a cdrom would render even the iso9660-header
unreadable, which is even better, as it fools possible spies into thinking
the cdrom is broken or blank.
Some time ago there was this solution on the list:
dd if=/dev/urandom of=/tmp/cryptfile bs=2048 count=333000
echo "my_passwort" | \
losetup -e aes --keybits 256 -p 0 /dev/loop1 /tmp/cryptfile
mkisofs -v -r -o /dev/loop1 /home/backup
...
It worked great; all those blocksize problems seem to be solved in the current
2.4 version (that is patch-int 2.4.18.3).
The point with this method is that one has to know the size of the container
file before writing into it through the loop-driver.
Wouldn't it be possible to write a small piece of code, which encrypts
stdin->stdout. This would compact the example above into one line like this:
mkisofs -xyz /home/backup | encrypt-on-the-fly > /tmp/cryptfile
or even burn it on the fly.
mkisofs -xyz /home/backup | encrypt-on-the-fly | cdrecord -
The encryption key would be requested from the console or from file or
whatever.
The trick here is writing this pipe-program which is is compatible with the
crypto-loop kernel driver so the data can later be transparently decrypted.
Main obstacles are the IV and the blocksize. The crypto-loop has no external
interface (or i failed to find it) so the separate encryption program would
have to duplicate the crypt-loop's functionality. Disregarding future
compatibility problems, this small program would be quite simple to code.
A huge problem could be to encrypt multi-session volumes and such. But as this
is quite problematic with the mkisofs/cdrecord pair anyway, i would ignore it
for now.
Now for the questions:
Has some one already coded this tool and could save me a day or two?
Does any one with more insight into the crypto-loop driver see a problem in
design with this solution? Can we reliably pre-calcucate the IV on the CD
before it is written?
Any other suggestions?
A big thanks to the people who made the crypto-loop as well-performing as we
know it.
Reos Zgium
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
