Date: Fri, 5 May 2000 20:02:00 -0700 (PDT) From: Kris Kennaway <kris@FreeBSD.org> To: Mark Murray <mark@grondar.za> Cc: "Andrew J. Korty" <ajk@iu.edu>, security@FreeBSD.ORG Subject: Re: Cryptographic dump(8) Message-ID: <Pine.BSF.4.21.0005050216330.130-100000@freefall.freebsd.org> In-Reply-To: <200005042022.WAA07642@grimreaper.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 4 May 2000, Mark Murray wrote:
> Could you break it in a way that would not compromise the crypto;
> that is break the stream at ${count} ${units}, rather than at
> "logical" boundaries, in such a way that the stream can be recovered
> at some point at the expense of maybe losing a ${block} if it
> contains a corruption?
I have something like this I use for my backups: it dumps the data as a
fixed volume-size (multi-part) .tgz file which is encrypted blockwise
(using openssl(1)) and then concatenated into the output stream - i.e.
each new .tgz subvolume is encrypted separately, so the maximum data loss
I get from a single bit media error (or in fact lots of errors clustered
within the same volume) is one volume's worth of plaintext.
Decryption verification is taken care of by the underlying tar/gzip header
- i.e. you decrypt the block and see if it's a valid .tgz file.
Kris
----
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <forsythe@alum.mit.edu>
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.BSF.4.21.0005050216330.130-100000>