On 12 May 2010 10:06, Malte Timmermann <> wrote:
> I agree (except for file names, at least OOo doesn't keep file names,
> but in the end the spec doesn't guide what to do anyway).
>
> I would like to avoid way 1+2, but to directly go with way 3.
>
> a) It's IMHO the better approach
> b) Don't introduce interim changes, This breaks compatibility twice, and
> I am even not not sure if somebody would implement them at all.
>
> Another not yet mentioned approach would be to use/allow standard zip
> encryption including directory encryption (instead of way 1+2, but not
> as a replacement for 3).
> But I don't know if this would allow for different algorithms, nor do I
> know if the standard zip encryption is considered to be strong.
> I guess there are reasons that it hasn't be considered for ODF
> encryption from the beginning...
I think there may also be IP concerns about using "standard" zip
encryption. From the application note:
"X. Incorporating PKWARE Proprietary Technology into Your Product
----------------------------------------------------------------
PKWARE is committed to the interoperability and advancement of the
.ZIP format. PKWARE offers a free license for certain technological
aspects described above under certain restrictions and conditions.
However, the use or implementation in a product of certain technological
aspects set forth in the current APPNOTE, including those with regard to
strong encryption, patching, or extended tape operations requires a
license from PKWARE. Please contact PKWARE with regard to acquiring
a license."
Regards
Bob
>
> Malte.
>
> wrote, On 05/11/10 19:42:
>> The approach we inherited from ODF 1.1 encrypts each file in the ZIP
>> independently. Although the contents of the files are not viewable due to
>> the encryption, there are bits of information that potential "leak", such
>> as:
>>
>> 1) The file size
>> 2) The file date
>> 3) The file name
>> 4) The file mime type
>> 5) The hash of the first 1024 bytes of the file
>>
>> For example, even in an encrypted document I could see a file name called
>> "big-secret-takeover-june-3.jpg" and know some information that the person
>> who wrote the encrypted document might be rather surprised to see in the
>> open.
>>
>> Although not required by ODF, an implementation, if it is clever, can
>> avoid some of these leakages. For example, the timestamp of the file can
>> be turned into the time of encryption rather than the original time stamp.
>> And the file name can be randomized rather than indicate the original
>> file name. This might be fine for ODF, since these time stamps and file
>> names are not necessary to be preserved. So long as as we preserve
>> referential integrity of the package, the names of images are not
>> significant.
>>
>> However we still should be concerned here. First, the reason we split
>> Part 3 into its own part was the believe that it could be useful for
>> purposes other than just ODF 1.2. Many of us hoped that it would other
>> uses. But I don't think we can assume that all uses can ignore the
>> original file names and time stamps. These might be significant for some
>> uses.
>>
>> Second, even within ODF, especially if we allow package extensions, we
>> might see items added to packages where the names of files (which may
>> ultimately end user-defined) cannot safely be renamed to random names. For
>> example, there may be referential integrity constraints that a generic ODF
>> processor is not aware of. Maybe there is RDF that points to a contained
>> image or other package resource. In any case, the approach is very
>> fragile.
>>
>> Finally, even without extensions, and with the use of randomized names, we
>> still leak information, based on knowing the size and hash of the first
>> 1024 bytes of the file. For example, if I have a copy of "
>> big-secret-takeover-june-3.jpg" I can easily check to see what encrypted
>> documents also contain that same image. I can similarly probe for any
>> other resource where I know in advance its size and or contents.
>>
>> There are three ways of getting around this problem. (Or at least two
>> that come to mind). One is to keep a "shadow directory" for the ZIP, that
>> contains the original names, time stamps, and sizes of the files. Encrypt
>> this "shadow directory" when the document is encrypted. For example
>> encrypted file, prepend it with some random bytes (not sure what is
>> optimal) in order to prevent data leakage of original size and hash of
>> first 1024 bytes.
>>
>> Another approach is to encode the original full path of the file, appended
>> with its timestamp, using the original derived key, base64 encode that,
>> and then write that out as the full path for the ZIP entry. That way you
>> do not need another file in the ZIP.
>>
>> The other way is to move to a whole-package encryption method, rather than
>> trying to do this file-by-file.
>>
>> -Rob
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail. Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
