On Jul 11, 2007, at 11:58 AM, Alan Altmark wrote:
Down, boy! Down! [I brandish a rolled-up newspaper in your general
direction] :-) There are issues surrounding compression and
encryption
that have nothing to do with secure network transmission provided
by the
SSL server. What to do if you want to encrypt a dump on a tape for
archive purposes and you don't have an encrypting tape drive?
Who said anything about *network* transmission?
I don't really understand your question though: if your tape drive
won't do it, then you gotta do the crypto in (possibly-coprocessor-
assisted) software, right? So you just encrypt each block via
your...well, "encrypting pipeline" is the best term I can quickly
come up with...on its way to the drive. You just need some method of
making sure that you don't shoeshine the drive by forcing it to wait
for blocks, but that's a simple matter of adjusting buffer sizes (and
if necessary buffering to disk) on the way. Sure, you need an
additional buffer to hold the encrypted blocks (as well as the
plaintext blocks) and you need the overhead of the encryption
facility, but, hey, no such thing as a free lunch. Assuming you pick
to standard (and correctly-implemented) ciphers, then whether you do
the en- or decryption in hardware or software simply becomes a
question of speed and price, not functionality.
And if you just want your data compressed, well, you were going to
compress it before you encrypted it anyway, right (to squeeze out as
much entropy as possible), so you just pick a null cipher and the
same pipelining mechanism, eh?
I mean, yeah, sure, it's not really that quite easy (key management
being the most glaring problem to me), but it does seem like there's
a lot of common data-block-manipulation-strategy you probably could
factor out.
Until you said it, I hadn't given any thought to using the SSL
server in
new and creative ways to accomplish file encryption. Hmmm......
veeeeerrrry interesting. ;-)
Oh.
Well, crap. Can we rewind so I can *charge* you for that idea?
Adam
