Encrypt the backup, or encrypt the files? - Security

This is a discussion on Encrypt the backup, or encrypt the files? - Security ; I currently do backups on a Linux server to DAT72 tapes using a home-grown script wrapped around afio (which is a better cpio). For off-site backup copies, management wants the backups encrypted. The documentation and examples with afio do this ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Encrypt the backup, or encrypt the files?

  1. Encrypt the backup, or encrypt the files?

    I currently do backups on a Linux server to DAT72 tapes using a home-grown
    script wrapped around afio (which is a better cpio). For off-site backup
    copies, management wants the backups encrypted. The documentation and
    examples with afio do this by replacing the per-file compression tool with
    gnupg. Roughly:
    (1) find ... -print0 |
    afio -ovz -0 -Z -U -P gpg -Q --symmetric ... -3 3 /dev/tape 3< ppfile
    The result is that each file is gpg-encrypted using the passphrase in
    ppfile before copying into the afio archive.

    Why not encrypt the whole backup instead? For tape output, I believe
    I will have to reblock the output as well. Something like:
    (2) find ... -print0 |
    afio -ov -0 ... - |
    gpg --symmetric --passphrase-file ppfile |
    dd obs=10240 of=/dev/tape

    I believe (2) is more secure, because with (1) the file names, dates, sizes
    etc. are clear-text. And some of those files have predictable content. But
    I think (2) is less reliable, in that a single unreadable block would make
    the rest of the backup unreadable.

    Comments?
    Which is better: encrypt the backup or encrypt the files?

  2. Re: Encrypt the backup, or encrypt the files?

    On Tue, 31 Oct 2006, in the Usenet newsgroup comp.os.linux.security, in article
    , ljb wrote:

    >I currently do backups on a Linux server to DAT72 tapes using a home-grown
    >script wrapped around afio (which is a better cpio). For off-site backup
    >copies, management wants the backups encrypted.


    Not unreasonable - what is the threat model? How are the tapes being
    stored (on AND off-site)? How are the tapes transferred to/from off-site?

    >I believe (2) is more secure, because with (1) the file names, dates, sizes
    >etc. are clear-text. And some of those files have predictable content.


    At the cost of some increase in complexity (renaming via lookup tables,
    pre-compressing the files before encryption, etc.), you may be able to
    reduce that exposure. Is that going to make enough of an improvement in
    security? Only you can answer that.

    >I think (2) is less reliable, in that a single unreadable block would make
    >the rest of the backup unreadable.


    Bingo

    >Comments?
    >Which is better: encrypt the backup or encrypt the files?


    "That depends." There is no set-piece answer, and much of it depends on
    your individual situation. Your whole backup (2) solution can be made less
    risky by duplicating the backups, and/or using quality tape/tape-drives,
    and so on, but when the Backup Gremlin decides it's your turn in hell, it
    won't be fun no matter what you do.

    Old guy

  3. Re: Encrypt the backup, or encrypt the files?

    >>...
    >>Which is better: encrypt the backup or encrypt the files?

    >
    > "That depends." There is no set-piece answer, and much of it depends on
    > your individual situation. Your whole backup (2) solution can be made less
    > risky by duplicating the backups, and/or using quality tape/tape-drives,
    > and so on, but when the Backup Gremlin decides it's your turn in hell, it
    > won't be fun no matter what you do.


    Thank you for your comments. I was afraid I was overlooking something,
    so your responses are helpful.

    I do recall a backup package that worked something like a RAID 5 array: It
    wrote "N" data blocks, then the N+1st was a redundancy check on the first
    "N". So in theory you could still read the data if one block in "N" was
    unreadable. That would mitigate the risk of overall-encrypted backups
    being unreadable after an error.

  4. Re: Encrypt the backup, or encrypt the files?

    ljb (06-10-31 02:52:37):

    > I currently do backups on a Linux server to DAT72 tapes using a
    > home-grown script wrapped around afio (which is a better cpio). For
    > off-site backup copies, management wants the backups encrypted. The
    > documentation and examples with afio do this by replacing the per-file
    > compression tool with gnupg. Roughly:
    > (1) find ... -print0 |
    > afio -ovz -0 -Z -U -P gpg -Q --symmetric ... -3 3 /dev/tape 3< ppfile
    > The result is that each file is gpg-encrypted using the passphrase in
    > ppfile before copying into the afio archive.
    >
    > Why not encrypt the whole backup instead? For tape output, I believe I
    > will have to reblock the output as well. Something like:
    > (2) find ... -print0 |
    > afio -ov -0 ... - |
    > gpg --symmetric --passphrase-file ppfile |
    > dd obs=10240 of=/dev/tape
    >
    > I believe (2) is more secure, because with (1) the file names, dates,
    > sizes etc. are clear-text. And some of those files have predictable
    > content. But I think (2) is less reliable, in that a single
    > unreadable block would make the rest of the backup unreadable.


    This really depends on the encryption mode you use. If you use CBC
    mode, then everything after the first broken block is unrecoverable.
    That is why I would suggest another mode instead. LRW mode should solve
    this problem, while not giving up a reasonable amount of secrecy.


    > Comments?
    > Which is better: encrypt the backup or encrypt the files?


    Certainly encrypting the whole backup is a lot more secure, because you
    achieve full secrecy. It's also faster and easier to deal with.

    By the way, GnuPG is not very suitable for filesystem encryption.
    You're going to be interested in dm-crypt, since it makes things much
    easier. With it you can also mount the backup regularly, if you know
    the key (however, that shouldn't be too practical on tape devices).


    Regards,
    E.S.

+ Reply to Thread