[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]