OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] Encryption and data leakage


I'd also be concerned about library support for that form of encryption. 
Specifically, if you have a ZIP library in your platform or language 
libraries, but it does not support ZIP encryption, it will be far easier 
to code a pre-ZIP encryption method than to modify the way your system 
library handles ZIPs.

-Rob


Bob Jolliffe <bobjolliffe@gmail.com> wrote on 05/12/2010 05:22:08 AM:

> 
> Re: [office] Encryption and data leakage
> 
> On 12 May 2010 10:06, Malte Timmermann <Malte.Timmermann@sun.com> 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.
> >
> > robert_weir@us.ibm.com 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
> >
> >



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]