[Dvdrtools-users] Re: crypt ISO image -- no longer ISO format, plus recoverability considerations

[Bryan J. Smith]

Quoting Alessio Sangalli <address@hidden>:
> This would be an interesting test.

If cdrecord can record any arbitrary "raw" data, then it will work.  But if it
expects some sort of header before recording, be it ISO9660 Red Book, Yellow
Book, UDF, etc..., it won't.  I'm assuming the latter, but I'm willing to be
proven wrong.

> I don't only want the files to be crypted, but even the content 
> shouldn't be guessed. A complete protection over which kind of data, 
> files, filenames are in the DVD.

Then consider archiving into tar or something else and then pipe it through
GnuPG (which also compresses).  I normally don't like this approach because it,
like compressing an entire filesystem, can be rendered useless with a _single_
byte error.  I like to balance privacy and recoverability equally.

So I'd take it one step further and still use per-file compression, _but_ give
the files totally _random_ names after GnuPG'ing them.  GnuPG stores the
original filename and will restore them upon decryption.

[ Hmmm, I see a script coming on that is a modification of my "back2cd".  ;-p ]

> A 'per-file' encryption is not so difficult to realize just before the
> actual image creation and I know how to do it.

???  I'm confused on your point  ???

> However I would like to protect the 'whole' dvd globally, I don't
> know if I can correctly express my need.

Since ISO9660/UDF don't define compressed/encrypted formats, I don't know what
to tell you.  Maybe it's time the Open Source community comes up with a ISO9660
"Black Book" (is that taken?) track format that adds track-wide encryption???

I was dumbfounded when the Austin Group decided against defining a "standard
compression" for the new ustar/POSIX-2001 format supported by pax.  They could
have at least selected LZ77, for which there is a BSD licensed implementation in
libz/gzip.

> I explain better the original idea:
> 1) I prepare my data
> 2) I generate an ISO image file with mkisofs
> 3) I encrypt it
> 4) I take the encrypted ISO image and I burn it to a dvd-r with 
> dvdrecord or cdrecord-hack

Er, it's not an "ISO image" once you encrypt, compress or otherwise modify it. 
The entire ISO header is _blown_away_ so it's nothing like ISO9660 anymore.

Again, I don't think you can just burn any arbitrary data organization with
cdrecord et al.  But I could be wrong.  Anyone?

> 5) I delete the data, the ISO, and the encrypted ISO from the hard
> disk 6) I put my dvd-r on the shelf for months
> when I need the data...

But if you incur a single byte error, you're entire disc will be toast from that
point on in the media.

> 7) I read the dvd with 'dd' on hard disk

Again, I think "dd" makes certain assumptions on the organization of a CD/DVD. 
But I could be wrong.

> 8) I decrypt it
> 9) I mount the decrypted ISO image file as loopback OR I burn a DVD-R 
> with it
> I think the only problem would be in step 4), probably the ISO image is
> not valid anymore and can't be burned on DVD.

That was my thought exactly.  I know you _can_ "write raw/direct" to the device,
but I don't know how "portable/readable" your media becomes in different drives
or, at least, on difference platforms.

> Stupid question: can I generate a local copy of a dvd (step 1) with dd?
> With data cd-roms I gave a: "dd if=/dev/hdc of=file.iso bs=2k" I don't
> know if this is ok with data DVD-roms, video DVD, whatever...

Yes.  *BUT* it _assumes_ the organization on the CD/DVD media is ISO9660 Yellow
Book (possibly others), at least under Linux.

I have never tried burning a file that is no longer in ISO/UDF format.

> on another mail I was told to simply generate the ISO, encrypt it, and
> then generate another ISO containing the encrypted ISO. This will 
> obviously work....

Er, I'd use a "streaming" archiving format that is a little more "robust," like
tar, cpio or their replacement, pax.  Of course, if you compress/encrypt it, a
single byte error at any point will render the recoverability features of
streaming tar/cpio/pax _useless_ at that point on-ward in your CD/DVD.

Unless GnuPG allows the use of a block compression-encryption pair I'm not
familiar with?  Is Blowfish, DES or AES symmetric ciphers (used to actually
encrypt the data, whereas the key to unlock it is asymetrically encrypted)
"block" recoverable?  What about its compression algorithm?  If it uses LZ77
(GZip), then I know it's _not_.

I know the BWT (BZip2) algorithm does, which can make them sometimes recoverable
sometimes in the blocks that follow a point of error.  Most proprietary hardware
comparession algorithms (in tape drives) also use block compression.

Understand I'm of the "anal recovery" type, I want to make sure my backups and
archives are at least partially recoverable.  Especially when it comes to
"flaky" MO media like CD-RW, DVD-RW and DVD+RW.


-- 
Bryan J. Smith, E.I. (BSECE)       Contact Info:  http://thebs.org
[ http://thebs.org/files/resume/BryanJonSmith_certifications.pdf ]
------------------------------------------------------------------
"Bryan J. Smith uses a modicum of talent and a membership in IEEE
 to harass others and show off" -- Peter Buxton