Date: Mon, 17 May 1999 12:45:09 +0930 (CST) From: Kris Kennaway <kkennawa@physics.adelaide.edu.au> To: Adam Shostack <adam@breakwater.homeport.org> Cc: nr1@ihug.co.nz, freebsd-security@FreeBSD.ORG Subject: Re: secure backup Message-ID: <Pine.OSF.4.10.9905171213420.28148-100000@bragg> In-Reply-To: <19990516223322.B1851@weathership.homeport.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 16 May 1999, Adam Shostack wrote: > You're worried about errors on the tape, I presume? You could > pipe the output of pgp through something that does redundant encoding, > such that errors on the tape are recoverable outside the tape. There > are some direct tradeoffs that you can find between bloat and > recoverability; as you add bits, your odds of being able to > reconstruct increase. Pipe the output of dump or tar or whatever you're using through bdes(1). You don't need the overhead of PGP unless you want a trusted third party to read the backup without knowing the encryption key. Pass the data through three rounds of bdes doing an encrypt, decrypt, followed by encrypt (with different keys, of course) and you've got yourself 3DES, which bdes doesn't seem to do natively. Make the keys random, and stick those in a PGP file if you like. Hmm, there seems to be a void of any general-purpose tools which provide error-correcting data encoding - but in this case do you really need it? It'll only multiply the size of your backup, and if you're using a reliable transport protocol between client and server (i.e. TCP) then this shouldn't be an issue. If your tape is dropping bits, then it would be a big problem if you were using it in the normal way (attached to local computer). I suppose the untrusted server could cause your data stream to be corrupted, but they could also cause it to never make the tape in the first place. Transport the data stream to the server using ssh -c none (no need for the overhead of another encryption layer unless you're really paranoid) - this still authenticates via RSA, so you have at least some assurance that no-one else can be sending data to the tape except you (the backup server process could have been silently replaced, so you don't actually know that your data is going to the tape, but I don't think it'd be easy to verify this). Of course, a malicious (super-)user could reverse-engineer the backup process on ther server and modify it to nullify ANY authentication measures (easy if this is a shell script) - so you can't really be sure that no-one else is writing data onto the tape, only that the data you do write which ends up on the tape is secure from decryption. In summary, there's only so much you can do if you don't trust the server - you still have to trust them to provide basic functions like actually writing your data to the tape. Kris > > Adam > > > On Mon, May 17, 1999 at 12:14:19PM +1200, nr1@ihug.co.nz wrote: > | Can anyone recommend how I should go about creating a backup to an untrusted > | machine that has the tape drive, and using an untrusted network. > | > | I'm a bit wary of encrypting the output of tar or dump, as a single byte error > | would make the rest of the backup useless. I'd like to encrypt (pgp?) each > | file separately as I go, so that a corrupted byte affects only one file on > | retrieval. Is there an existing way to do this, or should I hack tar or dump > | into doing it? > > -- > "It is seldom that liberty of any kind is lost all at once." > -Hume > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > ----- "That suit's sharper than a page of Oscar Wilde witticisms that's been rolled up into a point, sprinkled with lemon juice and jabbed into someone's eye" "Wow, that's sharp!" - Ace Rimmer and the Cat, _Red Dwarf_ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.4.10.9905171213420.28148-100000>