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

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.