Added some pros/cons inline.
robert_weir@us.ibm.com wrote, On 05/12/10 15:16:
> So what are our options for #3?
>
> Option 1) ZIP in a ZIP. So create document as if it is encrypted, then
> encrypt that as one file and STORE it in a container ZIP file that has
> manifest, mimetype and nothing else. That manifest lists the encryption
> parameters for the "inner" zip.
>
> PRO:
>
> Data leakage concerns go away.
>
> Better interaction with digital signatures.
>
> Simplifies the specification. We don't need to talk about pre-compressing
> before encrypting. That happens automatically.
And: Not only the signatures, but no other feature at all need to know
anything about encryption (except the encryption feature itself)
>
> CON:
>
> Will this be slower because of the double ZIP? I'm not quite sure. I
> think it might actually be faster because encrypting one big stream should
> be faster than encrypting many smaller streams. This is worth testing.
Might need more memory, in case you want to keep the decrypted zip in a
memory stream to avoid writing it to temp
>
> There is no opportunity for selective encryption. For example, cannot
> decide to expose metadata but not content. But this is not typical. And
> if really needed we could allow metadata to be shadowed in the outer
> container.
>
> Option 2) Don't have two-levels of ZIP, but maintain a shadow directory
> that is encrypted along with the concatenation of the files in the stream,
> maybe using the Unix tar method.
>
> PRO: Not sure it has advantages over 1)
>
> CON: Requires us to specify more, specifically our own conventions for a
> pre-compression, pre-encryption compound file.
And it doesn't solve the issue with encrypting a singed document
Malte.
>
> Option 3) Is there an option 3?
>
> -Rob
>
> Malte.Timmermann@Sun.COM wrote on 05/12/2010 05:06:09 AM:
>
>> From:
>>
>> Malte Timmermann