Re: building compatible zip files "by hand" that are encrypted and compressed

Bill,

Thanks for the input.  I'd love to hear about the
protocol you used in your system.

In the end, we do want all encryption, decryption,
compression, and decompression to happen on the client
workstation, and we want the server to know as little
about the client data as is possible.

We made the decision early to focus on web-based
restores with ZIPPED delivery of restore results,
mainly for ease of use.  We may eventually change our
approach and do it your way, but for now we want to
stick with ZIP downloads.

Our challenge is how to build those ZIP files on the
server, from the (already compressed and
encrypted)data stored on the server, so that the
client's unzip utility will expand it properly.

ed


--- bill davidsen <[email protected]> wrote:
> In article
> <20030919165105.92105.qmail-U+YAH3SPG2qA/[email protected]>
> you write:
> | Greg,
> | 
> | Thank you, that is very helpful information.
> | 
> | Supposing then I accept the vulnerable but
> universal
> | 96-bit encryption, how formidable do you think my
> two
> | tasks are:  1) Encrypting and compressing the
> files on
> | the "upstream" side, before the client sends them,
> and
> | 2) Building the ZIP file from the (already
> compressed
> | and encrypted) files later?
> | 
> | I can see already that if I compress the file on
> the
> | client before sending it to the server I must also
> | transmit the original file size to the server; and
> if
> | I eventually allow the end user to select from a
> menu
> | of encryption methods I must also transmit which
> | algorithm was used.  I can add those items to my
> | protocol very easily.  I'm wondering what else I
> might
> | need to send to the server so that it can
> construct a
> | valid ZIP file later.
> 
> Having done a distributed backup system in a
> previous life, I ask - why
> have the repository know anything about file format?
> Let the sending
> machine send you a file which you treat as a stream
> of bytes (only). Let
> the sender do encryption / decryption.
> 
> Background:
> 
> The system I built had a storage server which just
> got a message from a
> machine needing backup. The message included a task
> identifier and the
> size of the data. When storage was available the
> storage server sent a
> message to the client to send the data, which was
> just stored. This
> allowed the client to use any format, compression,
> or encryption
> desired, and the data was never touched on the
> storage server, so there
> were no issues with readable data for those things
> which mattered.
> 
> There was a backup policy scheduler which told the
> various servers it
> was time for a full or incremental backup, or the
> servers could initiate
> by themselves.
> 
> 
> -- 
> bill davidsen <[email protected]>
>   CTO, TMR Associates, Inc
> Doing interesting things with little computers since
> 1979.
> _______________________________________________
> Info-ZIP mailing list
> [email protected]
> http://lists.wku.edu/mailman/listinfo/info-zip


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com