Re: Ontape security when shipping tapes

kxk0912 wrote: > We have a need to ship a level-0 ontape backup that will contain > sensitive data. How secure is the data when backed up using ontape? > Could a potential threat use a UNIX utility such as dd to read the > tape? As Clive and Bozon said, the raw ON-Tape archive is a series of IDS page images plus some control information. It is readily decipherable for many purposes - especially things like names and SSN or credit card numbers. What they omitted to say was the IDS 10.00 supports archives to standard output and recovery from standard input. You can use that to avoid the intermediate copy to disk which they suggested. Note that when backing up, it is imperative to compress before you encrypt. Encrypted data is random looking and hence incompressible; compressed data also looks random, but encrypting it doesn't take up extra space. Obviously, the converse applies on restore - decrypt before decompress. Finally, make absolutely sure you know how you deal with recovery, and how you deal with recording the encryption keys. Do not send the keys in the same shipment as the tapes themselves. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/

Jonathan Leffler wrote: > > What they omitted to say was the IDS 10.00 supports archives to standard > output and recovery from standard input. One of my favorite features is the STDIO trick. The bang for the buck for implementing it must have made development happy. You can use that to avoid the > intermediate copy to disk which they suggested. Note that when backing > up, it is imperative to compress before you encrypt. Encrypted data is > random looking and hence incompressible; Do you really not get good compression on encrypted files? > compressed data also looks > random, but encrypting it doesn't take up extra space. I thought that some of the encryption algorithmns did take up extra space when they encrypted but I know so little about encryption it is almost one of the things that I pretend to be an expert on as opposed to one of the things I know enough about that I pretend to be an expert on. ;-) > Do not send the keys > in the same shipment as the tapes themselves. Yep, good advice.

bozon wrote: > Jonathan Leffler wrote: > > What they omitted to say was the IDS 10.00 supports archives to standard > > output and recovery from standard input. > > One of my favorite features is the STDIO trick. The bang for the buck > for implementing it must have made development happy. > > You can use that to avoid the > > intermediate copy to disk which they suggested. Note that when backing > > up, it is imperative to compress before you encrypt. Encrypted data is > > random looking and hence incompressible; > > Do you really not get good compression on encrypted files? Try it - no, you don't. If you get good compression, it is lousy encryption; if it is good encryption, you usually get a small expansion when you try to compress it. > > compressed data also looks > > random, but encrypting it doesn't take up extra space. > > I thought that some of the encryption algorithmns did take up extra > space when they encrypted but I know so little about encryption it is > almost one of the things that I pretend to be an expert on as opposed > to one of the things I know enough about that I pretend to be an expert > on. ;-) Yes, there is usually some small overhead. For example, the size will often be rounded up to the next larger multiple of 16 (sometimes 8 - depends on the encryption algorithm) bytes. But it depends on the size of the encryption unit. If the whole backup is a single unit, then 16 bytes extra on your 16 GB is lost in the noise. If the backup is divided into smaller sub-units, the overhead might be larger - perhaps up to 16 bytes per 1 MB. Note that the relevant algorithm (dictated by PKCS#5, IIRC) dictates that a 16 byte unit is encrypted as 32 bytes, but a 31 byte unit is also encrypted as 32 bytes. That's why you get the quantum effects in the size calculations for column-level encryption, incidentally. The encryption code might also include some control information - expanding the output a bit. However, the compression usually outweighs the expansion. Obviously, if you decide to use a base-64 encoding of the binary encrypted data, there is another expansion factor. It all depends - on many different factors. However, the space overhead due to encryption is usually small. > > Do not send the keys in the same shipment as the tapes themselves. > > Yep, good advice.

bozon wrote: > > Jonathan Leffler wrote: > > You can use that to avoid the >> intermediate copy to disk which they suggested. Note that when backing >> up, it is imperative to compress before you encrypt. Encrypted data is >> random looking and hence incompressible; > > Do you really not get good compression on encrypted files? Most compression routines work by finding common patterns and then replacing that common pattern by a token. Most encryption routines try very hard to obscure patterns because patterns make it easier to break the encryption. The net result is you'll generally end up with a much smaller file if you compress it and then encrypt the compressed file. > >> compressed data also looks >> random, but encrypting it doesn't take up extra space. > > I thought that some of the encryption algorithmns did take up extra > space when they encrypted but I know so little about encryption it is > almost one of the things that I pretend to be an expert on as opposed > to one of the things I know enough about that I pretend to be an expert > on. ;-) > > > >> Do not send the keys >> in the same shipment as the tapes themselves. > > Yep, good advice. >

Thanks Madison and Jonathan, for your very detailed answers. Jonathan Leffler wrote: > bozon wrote: > > Jonathan Leffler wrote: > > > What they omitted to say was the IDS 10.00 supports archives to standard > > > output and recovery from standard input. > > > > One of my favorite features is the STDIO trick. The bang for the buck > > for implementing it must have made development happy. > > > > You can use that to avoid the > > > intermediate copy to disk which they suggested. Note that when backing > > > up, it is imperative to compress before you encrypt. Encrypted data is > > > random looking and hence incompressible; > > > > Do you really not get good compression on encrypted files? > > Try it - no, you don't. If you get good compression, it is lousy > encryption; if it is good encryption, you usually get a small expansion > when you try to compress it. > > > > compressed data also looks > > > random, but encrypting it doesn't take up extra space. > > > > I thought that some of the encryption algorithmns did take up extra > > space when they encrypted but I know so little about encryption it is > > almost one of the things that I pretend to be an expert on as opposed > > to one of the things I know enough about that I pretend to be an expert > > on. ;-) > > Yes, there is usually some small overhead. For example, the size will > often be rounded up to the next larger multiple of 16 (sometimes 8 - > depends on the encryption algorithm) bytes. But it depends on the size > of the encryption unit. If the whole backup is a single unit, then 16 > bytes extra on your 16 GB is lost in the noise. If the backup is > divided into smaller sub-units, the overhead might be larger - perhaps > up to 16 bytes per 1 MB. Note that the relevant algorithm (dictated by > PKCS#5, IIRC) dictates that a 16 byte unit is encrypted as 32 bytes, > but a 31 byte unit is also encrypted as 32 bytes. That's why you get > the quantum effects in the size calculations for column-level > encryption, incidentally. The encryption code might also include some > control information - expanding the output a bit. However, the > compression usually outweighs the expansion. Obviously, if you decide > to use a base-64 encoding of the binary encrypted data, there is > another expansion factor. It all depends - on many different factors. > > However, the space overhead due to encryption is usually small. > > > > Do not send the keys in the same shipment as the tapes themselves. > > > > Yep, good advice.