on-the-fly encryption for cdrecord / cdrtools
(currently supporting cdrom encryption compatible with linux cryptoloop (>2.4.22) and linux dm-crypt (>2.6.4)

INDEX:

NEWS
Files / Download
Changelog

What is it ?
Why this patch ?
Little history of linux block device encryption support
Quick Howto
FAQ / known limitations
Technical Specifications
Examples


*PLEASE READ *   >>>> Reporting cdrecord - Bugs <<<<<<  *PLEASE READ*

As I am still receiving bug reports for issues that are absolutely not related to my patch, please read the following:

If you experience bugs or strange behaviour with cdrecord and this patch, first check whether or not the same problem
exists when using a "non-encryption-patched" version of cdrecord. In case of Gentoo, for example, remove the "on-the-fly-crypt"
USE flag from /etc/make.conf and emerge cdrtools again. In most (well, as for now - all) cases the problem persists... :-/
If so, it really has nothing to do with my patch and you might want to file a official bug report at the appropriate address.
(I just had to modify the bug report section of cdrecord because the author wants everyone modifying parts of it to do so.)

Anyway:
For all other cases (i.e. encryption related bugs or if the problem is really gone without my patch), please feel free to drop
me a note. Also please do not hesitate to provide feedback or suggestions if you would like to.

Thanks.


*NEWS*


14-Dec-2009:  Due to a variable name collision with the glibc-devel package (/usr/include/unistd.h) it was not possible to
                            compile an encryption-patched recent alpha-version cdrecord on newer systems like Ubuntu 9.10 or openSuSE 11.2.
                            The encryption patch is re-released as version 1.0a including minor internal modifications to avoid that issue.
                            (thanks to Jörg for bringing this to my attention)

05-May-2008: yep, the patch is not dead and still works.... ;-) the new version applies to cdrecord 2.01.01a38 !
                            Tested with i386 and x64. And remember to always eject and reload the CD after burning.

02-Oct-2006:   now it's finally 1.0 !
                            As there were no serious regressions / problems so far I thought it would be time to get out of "rc"-state.
                            It is suitable for cdrecord 2.01 and the 2.01.01 alphas, availably as different downloads as needed ....
                            (see the download-section)
                            The ToDo-list for a new version includes support for more key lengths and maybe even LUKS support to
                            allow better (i.e. easier) integration into desktop managers. And I think I will put the current 1.0 into
                            some kind of standalone tool - for those who still prefer piping and encrypting outside of cdrecord ;-))
08-May-2006:   1.0-rc3 is available.
                               Suitable for cdrecord-2.01.01a07 (i.e. alpha 07), as -rc2 did not apply properly due to some
                               internal changes. No other improvements oder major changes.
                               Some additional features (more ciphers etc.) are planned for a >1.0 version.
23-Jul-2005:   Again good news - a port for the DVD-OSS patch exists that enables burning encrypted DVDs !
                               Thanks to Robert Stockman for this one ! (please see the download section)
22-Jul-2005:   1.0-rc2.
                               I just removed my mail address because of the "bug-report-problem". No other changes.
                               Maybe this way people start to look at this page first ;-)
05-Feb-2005:   1.0-rc1 is there....
                               It is more decent with version numbering / tagging and therefore should allow for patching many
                               different minor releases of cdrecord / cdrtools. (well, given that is applies correctly ...)
                               I finished some internal clean-ups along with some minor improvements. (please see the ChangeLog)
                               And oh my ... this page is getting longer and longer.....  :-/                                                           
03-Jan-2005:   it's showtime for beta3. Finally found the time to add support for submitting the key from file.
                               And some other good news - I was recently informed about a win32 software that seems to be able to
                               access cdroms encrypted with my patch. That would be great ;-)
                               As soon as I did some testing I will let you know.                           
14-Dec-2004:   first RPM for *testing* is available. It is cdrecord-2.01 final including my patch and it is
                               built for SuSE Linux 9.0. It provides cdrecord (with encryption) and cdrecord-dvd.
                               A glibc-2.3 compiled binary is also available as stand-alone download.                           
08-Dec-2004:   beta2 released. This time it's just some security updates along with some text corrections.
                               Nothing really special. But now the passphrases are wiped out of memory as soon as
                               we do not need them anymore, i.e. the data encryption key is set up. The bad thing is
                               that they might still be visible in bash_history for some time :-(
                               I think I should add a parameter that allows retrieving the passphrase / key from a file.
                               In addition to that a config file in /etc would allow for completely transparent integration.
                               Well, that's the TODO for beta3 ;-))
03-Dec-2004:   ooooh my, and again it's been a long time ..... I just updated some links and the layout.
                               I am quite busy these days / weeks so I almost do not have the time for updates ...
                               My little GUI-wrapper-tool still needs some improvements as it still does not work perfectly
                               for every situation.  Especially if the calling program relies on cdrecord's feedback
                               ("gui-mode"), e.g. k3b and others. And I feel it would be nice to have it intelligent enough to
                               work under X *and* the console. Well - that's the dependencies I tried to get rid off with my patch ;-))
                               As some people still seem to be interested in RPMs, I think I will create some for the popular
                               distros. (Hm, ahem, I know I already said that some time ago .... if someone is willing to provide RPMs,
                               please feel free to contact me ! Maybe it could speed up things a little - thanks !)
03-Oct-2004:   ok, it's been a long time ... and the patch for cdrtools-2.01 final / release is out ...
                               There seem to be no serious problems so far, although I will start some cleanup
                               and checking the next days (or weeks). And I hope that I will have some time to
                               finish my little on-the-fly-encryption-gui tool, currently it's about 70%....
15-Aug-2004: again some text updates ...... and - for those who do not want to touch cdrecord - I am currently
                               working on a GUI driven tool that provides seamless integration of data encryption.
                               It will be very easy to integrate and work as a  wrapper for programs like cdrecord.
                               Whenever a program internally uses cdrecord, the data stream will be intercepted and a GUI dialog
                               will pop up asking for passphrase and the desired encryption style.
25-July-2004: just updated some text ..... and I think I will release some RPMs (SuSE, RedHat) for beta-testing soon ....
30-June-2004:  alpha4 released. Added support for submitting hex encoded passphrase.
29-June-2004:  alpha3 released. Just some minor fixes. Nothing special. Seems like it works quite well ;-)
26-June-2004:  alpha2 released. Added support for cryptoloop (>2.4.22, 2.6) compatible encryption (aes-256-cbc, plain "hash").                                           
25-June-2004:  initial release - alpha1. Support for dm-crypt compatible encryption (aes-256-cbc, sha-256 hash)


Files:

Patches for the cdrtools stable source:

1.0 for cdrtools 2.01: cdrtools-2.01-encrypt-1.0.diff.gz  (MD5: 1b3143eeeba0dfe3d488be691ec92e71)

Patches for the cdrtools alpha source:

1.0 for cdrtools >2.01.01a07: cdrtools-2.01.01a07-encrypt-1.0.diff.gz   (MD5: f9405732e36a452eb5bbc6c67d824fdc)
1.0 for cdrtools >2.01.01a11: cdrtools-2.01.01a11-encrypt-1.0.diff.gz   (MD5: c01d919748323aae145d39a8b1a818fb)
1.0 for cdrtools >2.01.01a38: cdrtools-2.01.01a38-encrypt-1.0.diff.gz   (MD5: 89d83e2c112a8fd205b51221ce106db1)
1.0a for cdrtools >2.01.01a69: cdrtools-2.01.01a69-encrypt-1.0a.diff.gz (MD5: 204670a212b3663b0fbea018991a2b8c)

older versions:
1.0-rc3 for cdrtools-2.01x (~2.01.01alpha11):
1.0-rc3 for cdrtools-2.01x (min. 2.01.01alpha07+): cdrtools-2.01-encrypt-1.0rc3.diff.gz  (MD5: 30b255971a94be9af7a8e572b562e790)
1.0-rc2 for cdrtools-2.01x: cdrtools-2.01-encrypt-1.0rc2.diff.gz  (MD5: 7230c43f6011185abbdb802724635d88)
1.0-rc1 for cdrtools-2.01x: cdrtools-2.01-encrypt-1.0rc1.diff.gz
beta3-patch for cdrtools-2.01: cdrtools-2.01-encrypt-beta3.diff.gz
beta2-patch for cdrtools-2.01: cdrtools-2.01-encrypt-beta2.diff.gz
beta1-patch for cdrtools-2.01: cdrtools-2.01-encrypt-beta1.diff.gz
alpha4-patch for cdrtools-2.01a27 / 32:   cdrtools-2.01a27-encrypt-alpha4.diff.gz   cdrtools-2.01a32-encrypt-alpha4.diff.gz
alpha3-patch for cdrtools-2.01a27:   cdrtools-2.01a27-encrypt-alpha3.diff.gz
alpha2-patch for cdrtools-2.01a27:  cdrtools-2.01a27-encrypt-alpha2.diff.gz
alpha1-patch for cdrtools-2.01a27:  cdrtools-2.01a27-encrypt-alpha1.diff.gz

!!! IMPORTANT:
!!!        Please verify your data after burning the CD  !!!


3rd party patches (provided "as is", no warranty or responsibility):

OSS-DVD project's DVD extension to cdrecord: http://www.crashrecovery.org/oss-dvd/cdrtools-2.01.01a01-ossdvd.patch.bz2
encryption patch for OSS-DVD-patched cdrecord: http://crashrecovery.org/oss-dvd/cdrtools-2.01.01a01-encrypt-1.0rc1.diff.gz


cdrecord related pages:

cdrecord homepage: http://cdrecord.berlios.de/old/private/cdrecord.html

cdrecord enhancements for burning DVDs:
    dvdrtools :  http://www.nongnu.org/dvdrtools/
    OSS DVD :  http://www.crashrecovery.org/oss-dvd.html



Changelog:


02-Oct-2006:   v1.0
   + same functionality as rc3, no changes
   + available as different downloads for the current -alpha series of cdrtools

08-May-2006:   1.0-rc3 (for cdrecord 2.01.01-alpha7)
    + Minor modifications  to apply correctly. No other changes.

22-Jul-2005:    1.0-rc2
    + Changed the bug report section. No other changes.

05-Feb-2005:    1.0-rc1
    + enhanced "-encstyle" parameter to be more standards compliant and to be ready for future encryption methods
    + internal cleanups
    + if the key is submitted by file and it is empty - disable encryption. This allows for some kind of "autoconfiguration".
       (empty key would not make much sense anyway....)

03-Jan-2005:   beta3
    + support for submitting key via file
    + minor corrections / cleanups

08-Dec-2004:   beta2
   + security updates (passphrase handling)
    + text corrections

03-Oct-2004:     beta1

30-Jun-2004:    alpha4
    + support for submitting hex-encoded passphrase

29-Jun-2004:    alpha3
    + minor fixes

26-Jun-2004:    alpha2
    +added support for cryptoloop compatibility (linux kernels >2.4.22, 2.6), -encstyle parameter added
    +fixed: using cdrecord with piped input could cause segmentation fault

25-Jun-2004:    alpha1 (first release ever)
    support only for aes-256 (cbc / plain chaining mode) with sha-256 hash)
    burn disks compatible with dm-crypt / cryptsetup.



What is it ?

It is a patch for Jörg Schilling's great cdrtools-package to enable support for burning encrypted disks on-the-fly. That's all ;-)
It it currenty beta quality - meant for testing purposes only.
Some ideas or parts were taken from:
    aespipe (C) 2002, 2003 Jari Ruusu
    implementation of the aes algorithm (C) 2001 Dr Brian Gladman

 
Why ? And why a patch for cdrecord ?

I've been using encrypted disks and partitions for quite a while now, and I am still very impressed about that .....
The only thing I  was missing for a long time was the possibility to create encrypted cdroms in an *easy* way....
I got used to my handmade scripts, which all worked well for me, but were not very handy.
In some cases I had to dump the iso to the hard disk, manually setup a encrypted loop device,
pipe the whole thing through it, and burn it afterwards. In other cases tools like aespipe did a very good
job, but again I had to use scripts. And most of my scripts had dependencies to other programs... or simply were
not flexible enough.
I thought it would be great to just drop a flag to cdrecord and make it burn with encryption.

So, one day, I decided to implement what I wanted - directly into cdrecord.
And it worked. It is not complete (by far), but now I can create encrypted cdroms within 1 easy line of bash "code". :-)

And then I thought, maybe others would also be interested in that patch, so why not make it available to the public ?

Some people already asked my why I really started to modify cdrecord instead of just improving my scripts ...
... well, there really seem to be many different opinions around about that. From my point of view the best place
for actually doing the encryption *would* be just before data enters the hardware device driver. That is how
cryptoloop, dm-crypt and many other implementations  actually do the job. Decryption is then done right after the data
comes out of the device / hardware driver. But while this works very well for "normal" block devices, cdroms are a little
special case here. That is, you do not read and write them the same way. While reading is very similar to reading a
hard disc (well, not exactly, see the FAQ about multi-session for example), writing has to be done completely different,
making it almost impossible to place encryption / decryption in the place mentioned above. So, where ?
Many things are possible, some of them are:

- completely in userland, cdrom independent.
    That would be like creating password protected ZIP files or a encrypted filesystem-in-a-file. Not what I wanted

- completely in userland, encrypting the ISO and burn it the usual way
    That is what the many scripts around are made for. You take a given ISO as "input" and get a encrypted ISO "output".
    Sure, you can use pipes to do that on-the-fly, without wasting hard drive space.
    The good and easy things are:
        - you do not have to touch software like cdrecord
        - you can change and modify your scripts as needed
    The complicated things are:
        - you still need some extra tools (e.g. aespipe), creating dependencies to them
        - you need transparent passphrase interaction, so be prepared for "console mode", "X mode" and so on
        - to use your scripts with other programs (like the great k3b, for example), you have to create some kind of
          "wrapper script" or "replacement script for cdrecord". It has to behave like cdrecord, answering things like "--help"
          or "--version". It also has to transport the needed feedback (e.g. cdrecord --gui mode) and errors back to the calling
          application. And it is never allowed to generate some output to stdout itself (error msg etc.), as it might disturb the
          piped data.
        - burn your working encrypted ISO with encryption-incompatible cdrom modes - it works, but your data cannot be read
           from the media again (see the FAQ). So be carefull here.
    So, it is all possible, sure, I used it that way myself quite a long time. But I did not really like that ....

- within the cd burning application
        a compatible software is needed. In case of open source software you could write a patch. That would work.
        But what if the software uses external programs to actually do the job? Well, you hardly have a chance to modify the data as
        it never really flows "through" it. In case of k3b, for example, the data used to create and burn the cdrom is handled via
        external programs (mkisofs, cdrecord ....) and pipes. And to make it flow through it, maybe using sockets or other named pipes ? Naaah....

- another external program used by your cd burning application
        you could patch your software to start another external program "between" mkisofs and cdrecord to do the encryption.
        That would be a very nice way to solve the encryption problem, and you could also create an extra gui tab for choosing
        the encryption and passphrase. I already thought about that myself. But it would be quite much work for having a
        for-one-software-only solution..... 

- between userland and kernel
        that is what my patch for cdrecord does. That keeps things quite simple and easy to use. But you have to modify cdrecord .....
        To integrate it into your favorite burning app just set user defined parameters for cdrecord there.


Please remember: My patch for cdrecord is only *one* possibility. I do not say it is the best  ;-)



Little history of linux block device encryption support ....

Encrypting block devices has become quite popular over the last years. If you take a look at that "evolution" progress
you will find several different ways and approaches.... sometimes making things incompatible with its predecessor.
Here is a short overview of what happend :

loop-AES (still maintained)

    First there was Jari Rusuu's "old" loop-AES. It was the first implementation that provided very good encryption and
had lots of great features, some of them still missing today in other (more popular) implementations - for example:
     - key iteration
     - MD5 IV generation
     - Multi-Key-Mode
     - storing the data encryption key in a GPG encrypted file.
.... making specific attacks much more theoretical (or even impossible)...
It consists of a kernel patch and some userland tools. Nobody really knows why it never made it into the mainstream
kernel, maybe it was just a bit too complicated because of its professional nature :-(

cryptoloop for linux kernels <2.4.22 (deprecated)

    The old cryptoloop patch for linux kernels <2.4.22 then provided a much simpler solution, but it resulted
in many discussions about how it was implemented and the way encryption was used. One of the problems was that
the problematic ecb mode was used by default - i.e. no chaining (and IV) at all.....  providing a kind of "weak security
by design". That does *not* mean it would be easily possible to break encryption, but it allows an attacker to derive some
quite sensitive information about the encrypted block device. I still wonder why so many commercial encryption tools
still use ecb-mode, but ...... well, maybe nobody knows, or nobody really cares .....

cryptoloop / cryptoapi for linux kernels >2.4.22 and >2.6.x (obviously deprecated in the near future)

    So it all got better (well, at least simpler ;-) with linux kernels >2.4.22, where a new cryptoloop / cryptoapi
(actually backported from kernel 2.6) was introduced as part of the mainstream kernel. Some of the great loop-AES
features were and are still missing, but the good thing is that the more secure cbc-chaining-mode is used by default.

dm-crypt for linux kernels >2.6.4

    And as of kernels >2.6.4 there is yet another, even more better solution to encrypting block devices :
A crypto target for the device mapper infrastructure. Wow. Impressive. Nothing else to say ;-)
For now security with dm-crypt is the same as with >2.4.22 cryptoloop, but there are already plans to implement
the lost features of loop-AES and even support more modern encryption methods in the (near) future ...
The big advantage lies in its clean and flexible design. Oh - and it is compatible to encrypted devices created with cryptoloop ;-)


QUICK HOWTO:

FROM SOURCE:

1. Grab the cdrtools source. (e.g. : ftp://ftp.berlios.de/pub/cdrecord/cdrtools-2.01.tar.bz2)
2. Extract the source & apply the appropriate patch
3. build the package ("gmake" or "make" in subdirectory cdrecord)
4. your cdrecord should be ready to use for encryption !

FROM RPM:

1. Download the RPM
2. Install / upgrade the RPM: e.g. rpm -vFh cdrecord-2.01-1001-i586.rpm
3. your cdrecord should be ready to use for encryption !

USE BINARY:

1. Download the binary cdrecord.
2. Place it under /usr/bin (or wherever you want)
3. your cdrecord should be ready to use for encryption !

Verify: cdrecord --version should bring up a version number "....-encrypt..."

you will be provided some additional parameters for cdrecord:

-encryption 
    enables the encryption feature
-encpass=xyz  
    set encryption passphrase to "xyz". Be sure not to use weak passwords !!
    The passwords are used as given, no seeds and no salt.

as of -alpha2 there is one additional parameter:
-encstyle=xyz
    where xyz can be:
       new : use encryption compatible with dm-crypt. Uses aes-256-cbc with sha-256 hash. (default, and same as in -alpha1)
       old : use encryption compatible with cryptoloop (linux kernels >2.4.22, 2.6.x). Uses aes-256-cbc with plain "hash".

as of -alpha4 there is one more additional parameter:
-encpasshex=abcd
    where abcd is the 2-byte hex encoded passphrase. Characters 0-255 can be submitted.

as of -beta3:
-encpassfile=/temp/cdrom.key
    reads the passphrase / key from the given file. (max. 32 bytes for 256 bit)



FAQ and known limitations

Q: Can I use the encryption feature with cdrom modes other than the default "data mode 1, 2048 byte" ?
A: As for now, no. You can tell it to cdrecord, but encryption will definitely abort with "unsupported blocksize".
    That is because of the given 512 byte encryption chain size. Data modes have to use block sizes that are integer multiples of
    512 to be valid for encryption. All other modes will not work - and if they would, they could not be decrypted again ;-)
   
Q: Can I burn encrypted audio cdroms ?
A: No. They would not work, either.

Q: What about encrypted multi-session cdroms ?
A: In theory they could work, given that:
        - you use the same passphrase for all sessions.
        - you take care of the session references manually or use "standalone" sessions
    But they do not work with the current implementations. Session information needed for multi-session-mount
    simply gets lost as soon as the device gets "looped". That is with cryptoloop and dm-crypt. Sorry.
    
Q: What about encrypted DVDs ?
A: Well, it depends - and yes, if you apply additional patches. There are many different DVD extensions for cdrecord:
       - cdrecord-ProDVD: It is currently kind of closed source. No source, no patch :-(
       Two currently popular open sourced projects providing DVD support:
            - dvdrtools at  http://www.nongnu.org/dvdrtools/ (patch to be done ..... )
            - OSS DVD extensions at http://www.crashrecovery.org/oss-dvd.html (patch exists - see the download section )

Q: I lost my key / passphrase. How can I get my data back ?
A: You can't. That is what encryption is good for.

Q: I heard about the watermark attacks against ecb and cbc encrypted devices using plain IV. Are they possible with my cdroms ?
A: Weaknesses are the same as with the "normal" block devices. The watermark attack allows to detect the presence
     of specially prepared files within the encrypted device without knowing the encryption key.
     But that does *not* mean it is possible to retrieve the data within the device ! The CBC mode used is considered fairly
     secure and much better than ECB. I know there are many other modes for IV generation and chaining available,
     but I just want to implement some common ones to keep usage simple. As soon as more secure modes become popular,
     I will try to integrate them into my patch.
     Please remember: the most important thing is to use strong passwords to prevent dictionary attacks.

Q: How secure are the generated cdroms ?
A:  As said above, it almost only depends on the given passphrase. Try to use more that 8 characters, use uppercase and
     lowercase, use letters and numbers, and try to use special characters like "!" or "$". Or use a good 256 bit random key
     if possible. The only chance then is to use a brute force attack to guess the key - well, and to wait some million years ;-)
   
Q: Can I use my encrypted cdroms with windows ?
A: There are some windows drivers around that provide access to encrypted cdroms. But none of them seems to be
     compatible to the current "encstyle's" for now. Well, most of them do not provide the neccessary information, anyway.
     But if someone knows about one, please let me know - thanks !
     Jan-05: There seems to be a software around that is able to use encrypted cdroms with windows - it is called "CrossCrypt".
     For more information please see http://www.scherrer.cc/crypt/.



Technical overview / specifications:

overview of encstyle parameters (detailed):
-encstyle cipher cipher key size
 cipher block size
 chain size
 mode
 IV
 passphrase & digest
 for use with e.g.
 since
old
 aes
 32 byte / 256 bits
 16 byte / 128 bits
 512 byte
 cbc
 plain
 plain
 cryptoloop (>2.4.22, 2.6)
 -alpha2
aes256-cbc-plain aes
 32 byte / 256 bits 16 byte / 128 bits 512 byte cbc plain
 plain
 cryptoloop (>2.4.22, 2.6) -1.0-rc1
new
 aes
 32 byte / 256 bits
 16 byte / 128 bits
 512 byte
 cbc
 plain
 sha-256, 32byte key
 dm-crypt (>2.6.4)
 -alpha2
aes256-cbc-sha256 aes
 32 byte / 256 bits 16 byte / 128 bits 512 byte cbc
 plain
 sha-256, 32byte key dm-crypt (>2.6.4) -1.0-rc1
ecb-mode (e.g. cryptoloop <2.4.22) is not supported. It is not very secure anyway....
I have already plans to support more encstyle's, but it depends a bit on how dm-crypt improves ;-)


EXAMPLES:

Create encrypted cdrom from standard iso image (for use with dm-crypt):
    From ISO image:
    cdrecord -dev=0,0,0 -encrypt -encpass=mypassword image.iso

    With piped input (coming from mkisofs, for example)
    mkisofs <.....> | cdrecord -dev=0,0,0 -encrypt -encpass=mypassword -

    Cryptsetup options for this cdrom would be:
   -c aes -s 256 -h sha256

    Sample usage (for cryptsetup >0.1, indicating read only with the "-r" flag):
        # cryptsetup -r -c aes -s 256 -h sha256 create ecdrom /dev/cdrom
            Enter passphrase: mypassword
        # mount  /dev/mapper/ecdrom /media/cdrom

        <... you can access your cdrom the usual way ...> 

       # umount /media/cdrom
       # cryptsetup remove ecdrom
       # eject /dev/cdrom

    cryptsetup-0.1 has a bug that prevents setting up encrypted mappers for read-only devices.
    You will have to workaround with losetup /dev/loop0 /dev/cdrom and use /dev/loop0 for cryptsetup.  
    Current versions (in CVS) already fixed this issue with the  "read only" flag "-r", and encrypted cdroms
    should work fine without any workarounds in cryptsetup >0.1 (not released yet ...  ).
   
   

Create an encrypted cdrom for use with cryptoloop (on linux kernels >2.4.22 and 2.6):

    From ISO image:
   cdrecord -dev=0,0,0 -encrypt -encpass=mypassword -encstyle=old image.iso

    Losetup options would be:
   -e aes-256

    Sample usage:
        # losetup -e aes-256 /dev/loop3 /dev/cdrom
            Password: mypassword
        # mount /dev/loop3 /media/cdrom

        <... you can access your cdrom the usual way ...>

        # umount /media/cdrom
        # losetup -d /dev/loop3
        # eject /dev/cdrom


    If you have a crypto patched util-linux available, you can directly use such cdroms with:

   mount -o encryption=aes-256 /dev/cdrom /media/cdrom

   eject /media/cdrom

    But be careful: there are many different versions of patched util-linux packages around,
    some of them being incompatible with each other. Especially some Debian-Packages have
    "patched-in auto-hashing" that could cause problems ...



Burn encrypted cdroms with k3b:

Just set user defined parameters for cdrecord:

Settings -> Configure k3b -> Programs -> User parameters -> Double click behind cdrecord
e.g. set -encrypt -encpass=mypassword

Then just burn your cds the usual way. Remember to remove the parameters to disable encryption !




Feedback is always welcome at burbon04 <at> gmx.de .



- Maximilian

14-Dec-2009