CD-ROM Encryption on-the-fly ?

[Reos Zgium <zgium@gmx.net>]

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/