Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


I don't know what the intention for LibreOffice is, but I can say that there are likely changes 
being made in anticipation of ODF 1.2 approval.

There has been extensive tightening to the Encryption specification in the Package description for 
ODF 1.2.  That specification is now separated into Part 3 of the ODF 1.2 Committee Specification 01 
which is now under Public Review as a Candidate OASIS Standard.

Consulting that document might provide some insight into changes that have occurred in the OO.o 
code base.  I'll take responsibility for what I hope is a more rigorous specification of package 
encryption in ODF 1.2, but I have no idea how this is tied to changes in the ODF 1.2-anticipating 
*Office.org implementations.

 - Dennis

DETAILS AND SPECULATIONS:

manifest:checksum-type="sha256-1k" is now recommended for the hash that is used to verify that the 
decryption appears to be correct, although consumers are expected to support both "sha1-1k" and 
"sha256-1k".  (Part 3 section 4.8.3)

manifest:start-key-generation-name="http://www.w3.org/2000/09/xmldsig#sha256";
is now recommended for the initial hash of the password that is then used for encryption-key 
derivation.  Consumers are required to support that value and the two other values,
"SHA1" and "http://www.w3.org/2000/09/xmldsg#sha1";.  (Part 3 section 4.8.6)

These are the only places where SHA256 has been explicitly introduced in conjunction with package 
encryption.  The PBKDF2 key-derivation is still based on HMAC-SHA-1 although there is now provision 
for alternative key-derivation algorithms.

I assume the change for manifest:start-key-generation-name is simply to provide a better hash and 
make it a bit harder to attack the password.  Some believe that the detection of SHA1 collisions 
makes these cases of SHA1 usage compromised.  That does not appear to be very relevant since the 
start-key is not recorded anywhere, in contrast with the protection-key hash values which an ODF 
document can be littered with.

The change for manifest:checksum-type does not appear cryptographically significant since it 
doesn't change anything with regard to how the manifest:checksum might be exploited as information 
leakage in aid of known-plaintext discovery/attack.

-----Original Message-----
From: libreoffice-bounces+dennis.hamilton=acm.org@lists.freedesktop.org 
[mailto:libreoffice-bounces+dennis.hamilton=acm.org@lists.freedesktop.org] On Behalf Of Markus 
Mohrhard
Sent: Sunday, June 26, 2011 11:27
To: libreoffice-dev
Subject: [Libreoffice] can no longer encrypt files if build with --disable-mozilla

Hello,

is it in our intention that we can no longer encrypt files if we build with --disable-mozilla? It 
seems that this was introduced through our latest merge from OOo. It seems that we need SHA-1 and 
SHA256 since the latest merge. SHA-1 still works but for SHA-256 we rely on NSS which is disabled 
if we build with --disable-mozilla.

Does anyone know why they added SHA-256?

Regards,
Markus



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.