Re: [office] Encryption and data leakage

[robert_weir@us.ibm.com]

OK. 

So it sounds like this:

1) Create ODF document as normal, with compressed (DEFLATE) streams in a 
ZIP

2) Encrypt the ZIP using Blowfish (legacy), AES (default) or another 
specified algorithm

3) The encrypted ZIP is then STORED in another ZIP contained.  We would 
also have at least a manifest (with the encryption parameters), a 
mimetype, and optionally a duplicate copy of any additional resources 
(thumbnail, metadata) that an implementation intentionally desired to be 
unencrypted.

If we do this we need a convention for locating the contained ZIP file. We 
could either have a well-known name like "encrypted.bin" or allow an 
arbitrary name but then have a content type that we use to locate it from 
the manifest.

Given the above, what does signing look like? 

-Rob

Bob Jolliffe <bobjolliffe@gmail.com> wrote on 05/12/2010 09:47:41 AM:
> 
> On 12 May 2010 14:16,  <robert_weir@us.ibm.com> wrote:
> > 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.
> >
> > 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.
> >
> > 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)
> 
> This option seems to be mostly recreating the functionality of a zip -
> an archive plus a directory.  I don't see much merit in going to the
> effort of specifying (and implementing) this kind of scheme unless it
> offers serious value add over 1.
> 
> >
> > CON: Requires us to specify more, specifically our own conventions for 
a
> > pre-compression, pre-encryption compound file.
> >
> > Option 3)  Is there an option 3?
> >
> > -Rob
> >
> > Malte.Timmermann@Sun.COM wrote on 05/12/2010 05:06:09 AM:
> >
> >> From:
> >>
> >> Malte Timmermann <Malte.Timmermann@Sun.COM>
> >>
> >> To:
> >>
> >> robert_weir@us.ibm.com
> >>
> >> Cc:
> >>
> >> office@lists.oasis-open.org
> >>
> >> Date:
> >>
> >> 05/12/2010 05:10 AM
> >>
> >> Subject:
> >>
> >> Re: [office] Encryption and data leakage
> >>
> >> Sent by:
> >>
> >> Malte.Timmermann@Sun.COM
> >>
> >> 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...
> >>
> >> 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
> >
> >