Re: Encrypted backups
On Tuesday 13 January 2004 17:17, Marcus Williams wrote: On 13/01/2004, Bill wrote: - make sure your kernel support encrypted loopback your encryption of choice - configure a crypto loop to your tape device losetup -e twofish /dev/loop0 /dev/nst0 Well, you learn a new thing every day. Never thought you could do that! What happens with media errors on the tape when you read it back? depends on the cipher mode you use: if using ECB (electronic codebook mode) every block of size AES_BLOCK_SIZE (e.g. for AES) is encrypted independently from each other - then media defects in one block should be a problem _only_ for the current block. Caveat: Statistical analysis are easier though if well-defined (known plaintext) values occur; refer to [1] for details. if using CBC (cipher block chaining mode) you will be more dependent from media errors because this mode adds a feedback mechanism - encryption results from previous blocks are taken into account when calculating the current one (plaintext block is XORed with previous ciphertext block). I guess that you will lose all blocks starting from the block having the media defect ;-( Instead of specifying /dev/nst0 as loopback target device just specify a local file myfile created with dd if=/dev/zero of=/tmp/myfile bsize=1024,count=...,skip=...), then you can simulate tape errors manually by changing the file using a hex editor - just try to recover afterwards ;-) Regards, Klaus [1] Schneier Bruce: Applied Cryptography. 2nd edition. Chapter 9. -- Dipl.-Ing. Klaus Holler gmx.at after kho@ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Encrypted backups
On Thu, 2004-01-15 at 12:34, Klaus Holler wrote: Well, you learn a new thing every day. Never thought you could do that! What happens with media errors on the tape when you read it back? depends on the cipher mode you use: ... snip ... if using CBC (cipher block chaining mode) you will be more dependent from media errors because this mode adds a feedback mechanism - encryption results from previous blocks are taken into account when calculating the current one (plaintext block is XORed with previous ciphertext block). I guess that you will lose all blocks starting from the block having the media defect ;-( It will only affect two blocks: the block with the error, and the next block (which will be XORed with the corrupted cipherblock after decrypting). The subsequent blocks will be fine. ECB mode would affect only one block, but is much less secure against several attacks (especially known plaintext attacks). There are other cipher modes as well, some with less propogation of data corruption in the ciphertext. But CBC is the generally preferred mode for security reasons. In practice, I'd expect that the archive format will propogate bit flips more than the encoding scheme. -Bill -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Encrypted backups
On Tuesday 13 January 2004 17:17, Marcus Williams wrote: On 13/01/2004, Bill wrote: - make sure your kernel support encrypted loopback your encryption of choice - configure a crypto loop to your tape device losetup -e twofish /dev/loop0 /dev/nst0 Well, you learn a new thing every day. Never thought you could do that! What happens with media errors on the tape when you read it back? depends on the cipher mode you use: if using ECB (electronic codebook mode) every block of size AES_BLOCK_SIZE (e.g. for AES) is encrypted independently from each other - then media defects in one block should be a problem _only_ for the current block. Caveat: Statistical analysis are easier though if well-defined (known plaintext) values occur; refer to [1] for details. if using CBC (cipher block chaining mode) you will be more dependent from media errors because this mode adds a feedback mechanism - encryption results from previous blocks are taken into account when calculating the current one (plaintext block is XORed with previous ciphertext block). I guess that you will lose all blocks starting from the block having the media defect ;-( Instead of specifying /dev/nst0 as loopback target device just specify a local file myfile created with dd if=/dev/zero of=/tmp/myfile bsize=1024,count=...,skip=...), then you can simulate tape errors manually by changing the file using a hex editor - just try to recover afterwards ;-) Regards, Klaus [1] Schneier Bruce: Applied Cryptography. 2nd edition. Chapter 9. -- Dipl.-Ing. Klaus Holler gmx.at after kho@
Re: Encrypted backups
On Thu, 2004-01-15 at 12:34, Klaus Holler wrote: Well, you learn a new thing every day. Never thought you could do that! What happens with media errors on the tape when you read it back? depends on the cipher mode you use: ... snip ... if using CBC (cipher block chaining mode) you will be more dependent from media errors because this mode adds a feedback mechanism - encryption results from previous blocks are taken into account when calculating the current one (plaintext block is XORed with previous ciphertext block). I guess that you will lose all blocks starting from the block having the media defect ;-( It will only affect two blocks: the block with the error, and the next block (which will be XORed with the corrupted cipherblock after decrypting). The subsequent blocks will be fine. ECB mode would affect only one block, but is much less secure against several attacks (especially known plaintext attacks). There are other cipher modes as well, some with less propogation of data corruption in the ciphertext. But CBC is the generally preferred mode for security reasons. In practice, I'd expect that the archive format will propogate bit flips more than the encoding scheme. -Bill
Re: Encrypted backups
On Tue, Jan 13, 2004 at 10:19:12AM +, Marcus Williams wrote: I am investigating ways of producing encrypted backups. You may also want to look into aespipe at http://loop-aes.sf.net HTH, DaCa. -- Danny Cautaert, Zopista and Pythoneer using Adamantix, FreeBSD Debian Write me in Dutch, French or English GnuPG encrypted email preferred Meet me at FOSDEM * 21 22 february, Brussels (BE) * http://fosdem.org or DebConf4 * 26/5-2/6, Porto Alegre (BR) * http://debconf.org/debconf4 or at Guadec * 28 - 30 June, Kristiansand (NO) * http://2004.guadec.org or at the LSM/RMLL * 6-10 July, Bordeaux (FR) * http://lsm2004.abul.org pgp0.pgp Description: PGP signature
Re: Encrypted backups
On Tue, Jan 13, 2004 at 10:19:12AM +, Marcus Williams wrote: I am investigating ways of producing encrypted backups. You may also want to look into aespipe at http://loop-aes.sf.net HTH, DaCa. -- Danny Cautaert, Zopista and Pythoneer using Adamantix, FreeBSD Debian Write me in Dutch, French or English GnuPG encrypted email preferred Meet me at FOSDEM * 21 22 february, Brussels (BE) * http://fosdem.org or DebConf4 * 26/5-2/6, Porto Alegre (BR) * http://debconf.org/debconf4 or at Guadec * 28 - 30 June, Kristiansand (NO) * http://2004.guadec.org or at the LSM/RMLL * 6-10 July, Bordeaux (FR) * http://lsm2004.abul.org pgphqP6vmAYw5.pgp Description: PGP signature
Encrypted backups
Hi - I am investigating ways of producing encrypted backups. Currently I use afio and gpg (via tob) with something like: afio -b 10240 -c 1000 -U -Z -P gpg -Q --symmetric -Q \ --passphrase-fd=3 -Q --no-verbose -Q --batch -Q --no-options \ -3 3 -o /dev/nst0 $FILELIST 3$PASSPHRASE where $FILELIST is the list of files, and $PASSPHRASE is a path to a file containing the passphrase for the backup set. After a few tests, this method appears to be extremely slow (on a simple 4mb archive, non encrypted method takes less than .5 secs, encrypted takes about 7 secs) compared to non-encrypted backup sets (which I was expecting). Does anyone know of ways to speed the process up? Are there any other ways of getting an encrypted backup set that might be faster? Thanks Marcus -- Marcus Williams -- http://www.quintic.co.uk Quintic Ltd, 39 Newnham Road, Cambridge, UK This message is private [ ] public [*] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Encrypted backups
On 13/01/2004, [EMAIL PROTECTED] wrote: First of all, don't use the 'Z' option. GPG compresses itself and this would slow down the process a lot. I'm pretty sure the 'Z' option is needed - coupled with the 'P' option that tells afio to 'compress' using an external program that happens to be gpg. I've also tried switching off compression on gpg (by adding -Q -z0) but that doesnt speed up the backup either. Whats annoying is, I think the main slow down isnt from the encryption, its from having to start gpg for every file in the backup (afio compresses file by file). Encrypting a 4mb file on its own is relatively quick with gpg. I cant backup to a file based archive, encrypt that and write the encrypted archive to tape in case of media errors. I'm assuming that even a 1 bit error in an encrypted archive will break the whole archive, or at least the rest of the archive following the error. This is what afio is good for because a media error only corrupts the file that it occurs in, not the whole archive. [I also neglected to mention that I need to backup to tape as the tapes are taken offsite as a further security measure (in case of fire etc). This rules out backups to encrypted filesystems on a harddrive as hard drives are easily breakable (if dropped for instance)] Thanks, Marcus -- Marcus Williams -- http://www.quintic.co.uk Quintic Ltd, 39 Newnham Road, Cambridge, UK This message is private [ ] public [*] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Encrypted backups
Hi Marcus, * Marcus Williams [EMAIL PROTECTED] wrote: I am investigating ways of producing encrypted backups. Currently I use afio and gpg (via tob) with something like: Did you try duplicity? - Alexander signature.asc Description: Digital signature
Re: Encrypted backups
On 13/01/2004, Alexander Neumann wrote: Did you try duplicity? No - I just took a look at it though and I suspect that its not an option because it uploads the encrypted archive offsite. Not really an option on our ADSL line (we're talking about 60+Gb of data on a full backup) Thanks Marcus -- Marcus Williams -- http://www.quintic.co.uk Quintic Ltd, 39 Newnham Road, Cambridge, UK This message is private [ ] public [*] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Encrypted backups
First of all, don't use the 'Z' option. GPG compresses itself and this would slow down the process a lot. On 13-Jan-2004 10:19:12, Marcus Williams wrote: Hi - I am investigating ways of producing encrypted backups. Currently I use afio and gpg (via tob) with something like: afio -b 10240 -c 1000 -U -Z -P gpg -Q --symmetric -Q \ --passphrase-fd=3 -Q --no-verbose -Q --batch -Q --no-options \ -3 3 -o /dev/nst0 $FILELIST 3$PASSPHRASE where $FILELIST is the list of files, and $PASSPHRASE is a path to a file containing the passphrase for the backup set. After a few tests, this method appears to be extremely slow (on a simple 4mb archive, non encrypted method takes less than .5 secs, encrypted takes about 7 secs) compared to non-encrypted backup sets (which I was expecting). Does anyone know of ways to speed the process up? Are there any other ways of getting an encrypted backup set that might be faster? Thanks Marcus -- Marcus Williams -- http://www.quintic.co.uk Quintic Ltd, 39 Newnham Road, Cambridge, UK This message is private [ ] public [*] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- mit freundlichen Gruessen / with friendly regards Michael Buchholz MCI Group Office: +49 231 9721192 [EMAIL PROTECTED] Sebrathweg 20 Mobile: +49 231 9479858 EMEA DRSS Support44149 Dortmund, Germany Fax...: +49 231 9721207 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Encrypted backups
Hi Marcus, * Marcus Williams [EMAIL PROTECTED] wrote: On 13/01/2004, Alexander Neumann wrote: Did you try duplicity? No - I just took a look at it though and I suspect that its not an option because it uploads the encrypted archive offsite. Not really an option on our ADSL line (we're talking about 60+Gb of data on a full backup) You are able to store the backup-files on a local disk... - Alexander signature.asc Description: Digital signature
Re: Encrypted backups
[I meant to send this to the list] On 13/01/2004, Alexander Neumann wrote: You are able to store the backup-files on a local disk... Yes, but then we lose the ability to take them offsite. Well, unless I then move them to a tape. Worth thinking about though. Thanks Marcus -- Marcus Williams -- http://www.quintic.co.uk Quintic Ltd, 39 Newnham Road, Cambridge, UK This message is private [ ] public [*] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Encrypted backups
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: First of all, don't use the 'Z' option. GPG compresses itself and this would slow down the process a lot. Don't you have a working email-addres or are you trying to DoS the owner of please.de? $ host -t mx please.de please.de MX 10 0700supergeil.de $ nc 0700supergeil.de smtp 220 good morning helo foo 250 hello! mail from: [EMAIL PROTECTED] 250 ok rcpt to: [EMAIL PROTECTED] 500 unknown user quit 250 ok That's ridiculous! - Alexander signature.asc Description: Digital signature
Re: Encrypted backups
Hi Marcus, * Marcus Williams [EMAIL PROTECTED] wrote: [I meant to send this to the list] Thanks. I was just writing a mail about honoring the Mail-Followup-To:-Header... ;) On 13/01/2004, Alexander Neumann wrote: You are able to store the backup-files on a local disk... Yes, but then we lose the ability to take them offsite. Hu? Why that? Using duplicity you usually end up with a lot of files (all around 5MB in size) and you are freee to move them whereever you like. - Alexander signature.asc Description: Digital signature
Re: Encrypted backups
On 13/01/2004, Alexander Neumann wrote: * Marcus Williams [EMAIL PROTECTED] wrote: [I meant to send this to the list] Thanks. I was just writing a mail about honoring the Mail-Followup-To:-Header... ;) [snip] Sigh.. one of my wish list items for TheBat! is proper reply actions such as this. One day I'll get my arse into gear and try to write a macro for it but until then. You are able to store the backup-files on a local disk... Yes, but then we lose the ability to take them offsite. Hu? Why that? Using duplicity you usually end up with a lot of files (all around 5MB in size) and you are freee to move them whereever you like. [snip] Oh, ok. Perhaps I will give it a try. Obviously the next problem will be how stable it is (theres mention of use in non-production environment on the homepage). This is for my company's backups so it has to be rock solid. Cheers Marcus -- Marcus Williams -- http://www.quintic.co.uk Quintic Ltd, 39 Newnham Road, Cambridge, UK This message is private [ ] public [*] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Encrypted backups
Hello, Here's something I like: - make sure your kernel support encrypted loopback your encryption of choice - configure a crypto loop to your tape device losetup -e twofish /dev/loop0 /dev/nst0 - backup or restore as usual, using /dev/loop0 as a tape device - unconfigure the loop losetup -d /dev/loop0 It's kernel-side, very simple, and sould be fast enough... Bill Hi - I am investigating ways of producing encrypted backups. Currently I use afio and gpg (via tob) with something like: afio -b 10240 -c 1000 -U -Z -P gpg -Q --symmetric -Q \ --passphrase-fd=3 -Q --no-verbose -Q --batch -Q --no-options \ -3 3 -o /dev/nst0 $FILELIST 3$PASSPHRASE where $FILELIST is the list of files, and $PASSPHRASE is a path to a file containing the passphrase for the backup set. After a few tests, this method appears to be extremely slow (on a simple 4mb archive, non encrypted method takes less than .5 secs, encrypted takes about 7 secs) compared to non-encrypted backup sets (which I was expecting). Does anyone know of ways to speed the process up? Are there any other ways of getting an encrypted backup set that might be faster? Thanks Marcus -- Marcus Williams -- http://www.quintic.co.uk Quintic Ltd, 39 Newnham Road, Cambridge, UK This message is private [ ] public [*] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Billy Nadeau - [EMAIL PROTECTED] Services internet Sanac / Sanac internet Services -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Encrypted backups
On 13/01/2004, Bill wrote: - make sure your kernel support encrypted loopback your encryption of choice - configure a crypto loop to your tape device losetup -e twofish /dev/loop0 /dev/nst0 Well, you learn a new thing every day. Never thought you could do that! What happens with media errors on the tape when you read it back? Marcus -- Marcus Williams -- http://www.quintic.co.uk Quintic Ltd, 39 Newnham Road, Cambridge, UK This message is private [ ] public [*] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Encrypted backups
Hi - I am investigating ways of producing encrypted backups. Currently I use afio and gpg (via tob) with something like: take a look at loop-aes and aespipe. http://loop-aes.sourceforge.net/loop-AES.README http://loop-aes.sourceforge.net/aespipe.README gaetano -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Encrypted backups
Hi - I am investigating ways of producing encrypted backups. Currently I use afio and gpg (via tob) with something like: afio -b 10240 -c 1000 -U -Z -P gpg -Q --symmetric -Q \ --passphrase-fd=3 -Q --no-verbose -Q --batch -Q --no-options \ -3 3 -o /dev/nst0 $FILELIST 3$PASSPHRASE where $FILELIST is the list of files, and $PASSPHRASE is a path to a file containing the passphrase for the backup set. After a few tests, this method appears to be extremely slow (on a simple 4mb archive, non encrypted method takes less than .5 secs, encrypted takes about 7 secs) compared to non-encrypted backup sets (which I was expecting). Does anyone know of ways to speed the process up? Are there any other ways of getting an encrypted backup set that might be faster? Thanks Marcus -- Marcus Williams -- http://www.quintic.co.uk Quintic Ltd, 39 Newnham Road, Cambridge, UK This message is private [ ] public [*]
RE: Encrypted backups
First of all, don't use the 'Z' option. GPG compresses itself and this would slow down the process a lot. On 13-Jan-2004 10:19:12, Marcus Williams wrote: Hi - I am investigating ways of producing encrypted backups. Currently I use afio and gpg (via tob) with something like: afio -b 10240 -c 1000 -U -Z -P gpg -Q --symmetric -Q \ --passphrase-fd=3 -Q --no-verbose -Q --batch -Q --no-options \ -3 3 -o /dev/nst0 $FILELIST 3$PASSPHRASE where $FILELIST is the list of files, and $PASSPHRASE is a path to a file containing the passphrase for the backup set. After a few tests, this method appears to be extremely slow (on a simple 4mb archive, non encrypted method takes less than .5 secs, encrypted takes about 7 secs) compared to non-encrypted backup sets (which I was expecting). Does anyone know of ways to speed the process up? Are there any other ways of getting an encrypted backup set that might be faster? Thanks Marcus -- Marcus Williams -- http://www.quintic.co.uk Quintic Ltd, 39 Newnham Road, Cambridge, UK This message is private [ ] public [*] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- mit freundlichen Gruessen / with friendly regards Michael Buchholz MCI Group Office: +49 231 9721192 [EMAIL PROTECTED] Sebrathweg 20 Mobile: +49 231 9479858 EMEA DRSS Support44149 Dortmund, Germany Fax...: +49 231 9721207
Re: Encrypted backups
Hi Marcus, * Marcus Williams [EMAIL PROTECTED] wrote: On 13/01/2004, Alexander Neumann wrote: Did you try duplicity? No - I just took a look at it though and I suspect that its not an option because it uploads the encrypted archive offsite. Not really an option on our ADSL line (we're talking about 60+Gb of data on a full backup) You are able to store the backup-files on a local disk... - Alexander signature.asc Description: Digital signature
Re: Encrypted backups
[I meant to send this to the list] On 13/01/2004, Alexander Neumann wrote: You are able to store the backup-files on a local disk... Yes, but then we lose the ability to take them offsite. Well, unless I then move them to a tape. Worth thinking about though. Thanks Marcus -- Marcus Williams -- http://www.quintic.co.uk Quintic Ltd, 39 Newnham Road, Cambridge, UK This message is private [ ] public [*]
Re: Encrypted backups
On 13/01/2004, Alexander Neumann wrote: Did you try duplicity? No - I just took a look at it though and I suspect that its not an option because it uploads the encrypted archive offsite. Not really an option on our ADSL line (we're talking about 60+Gb of data on a full backup) Thanks Marcus -- Marcus Williams -- http://www.quintic.co.uk Quintic Ltd, 39 Newnham Road, Cambridge, UK This message is private [ ] public [*]
Re: Encrypted backups
Hi Marcus, * Marcus Williams [EMAIL PROTECTED] wrote: [I meant to send this to the list] Thanks. I was just writing a mail about honoring the Mail-Followup-To:-Header... ;) On 13/01/2004, Alexander Neumann wrote: You are able to store the backup-files on a local disk... Yes, but then we lose the ability to take them offsite. Hu? Why that? Using duplicity you usually end up with a lot of files (all around 5MB in size) and you are freee to move them whereever you like. - Alexander signature.asc Description: Digital signature
Re: Encrypted backups
Hello, Here's something I like: - make sure your kernel support encrypted loopback your encryption of choice - configure a crypto loop to your tape device losetup -e twofish /dev/loop0 /dev/nst0 - backup or restore as usual, using /dev/loop0 as a tape device - unconfigure the loop losetup -d /dev/loop0 It's kernel-side, very simple, and sould be fast enough... Bill Hi - I am investigating ways of producing encrypted backups. Currently I use afio and gpg (via tob) with something like: afio -b 10240 -c 1000 -U -Z -P gpg -Q --symmetric -Q \ --passphrase-fd=3 -Q --no-verbose -Q --batch -Q --no-options \ -3 3 -o /dev/nst0 $FILELIST 3$PASSPHRASE where $FILELIST is the list of files, and $PASSPHRASE is a path to a file containing the passphrase for the backup set. After a few tests, this method appears to be extremely slow (on a simple 4mb archive, non encrypted method takes less than .5 secs, encrypted takes about 7 secs) compared to non-encrypted backup sets (which I was expecting). Does anyone know of ways to speed the process up? Are there any other ways of getting an encrypted backup set that might be faster? Thanks Marcus -- Marcus Williams -- http://www.quintic.co.uk Quintic Ltd, 39 Newnham Road, Cambridge, UK This message is private [ ] public [*] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Billy Nadeau - [EMAIL PROTECTED] Services internet Sanac / Sanac internet Services
Re: Encrypted backups
On 13/01/2004, Alexander Neumann wrote: * Marcus Williams [EMAIL PROTECTED] wrote: [I meant to send this to the list] Thanks. I was just writing a mail about honoring the Mail-Followup-To:-Header... ;) [snip] Sigh.. one of my wish list items for TheBat! is proper reply actions such as this. One day I'll get my arse into gear and try to write a macro for it but until then. You are able to store the backup-files on a local disk... Yes, but then we lose the ability to take them offsite. Hu? Why that? Using duplicity you usually end up with a lot of files (all around 5MB in size) and you are freee to move them whereever you like. [snip] Oh, ok. Perhaps I will give it a try. Obviously the next problem will be how stable it is (theres mention of use in non-production environment on the homepage). This is for my company's backups so it has to be rock solid. Cheers Marcus -- Marcus Williams -- http://www.quintic.co.uk Quintic Ltd, 39 Newnham Road, Cambridge, UK This message is private [ ] public [*]
Re: Encrypted backups
* [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: First of all, don't use the 'Z' option. GPG compresses itself and this would slow down the process a lot. Don't you have a working email-addres or are you trying to DoS the owner of please.de? $ host -t mx please.de please.de MX 10 0700supergeil.de $ nc 0700supergeil.de smtp 220 good morning helo foo 250 hello! mail from: [EMAIL PROTECTED] 250 ok rcpt to: [EMAIL PROTECTED] 500 unknown user quit 250 ok That's ridiculous! - Alexander signature.asc Description: Digital signature
Re: Encrypted backups
On 13/01/2004, Bill wrote: - make sure your kernel support encrypted loopback your encryption of choice - configure a crypto loop to your tape device losetup -e twofish /dev/loop0 /dev/nst0 Well, you learn a new thing every day. Never thought you could do that! What happens with media errors on the tape when you read it back? Marcus -- Marcus Williams -- http://www.quintic.co.uk Quintic Ltd, 39 Newnham Road, Cambridge, UK This message is private [ ] public [*]
Re: Encrypted backups
Hi Marcus, * Marcus Williams [EMAIL PROTECTED] wrote: I am investigating ways of producing encrypted backups. Currently I use afio and gpg (via tob) with something like: Did you try duplicity? - Alexander signature.asc Description: Digital signature
Re: Encrypted backups
Hi - I am investigating ways of producing encrypted backups. Currently I use afio and gpg (via tob) with something like: take a look at loop-aes and aespipe. http://loop-aes.sourceforge.net/loop-AES.README http://loop-aes.sourceforge.net/aespipe.README gaetano
