openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: [UX] UI options for document encryption
Date Fri, 07 Dec 2012 18:26:02 GMT
Please see <https://issues.apache.org/ooo/show_bug.cgi?id=121141> in addressing security
vs protection in the UX also.

 1. CHOICE OF ENCRYPTION ALGORITHM

It is important to appreciate that there is no recommendation about AES for the ODF 1.2 manifest:algorithm-name.
 The only mandated algorithm for conformant ODF 1.2 documents, producers, and consumers is
Blowfish CFB.  Other encryptions defined in XML Encryption 1.0 are allowed in conforming documents
but there is no interoperability provision for them in ODF 1.2.

The choice for Save with Password should be simply whether to use ODF 1.0/1.1/1.2 Blowfish
or (for ODF 1.2 only) AES-256.  

 2. HASHING THE START KEY

The only place where there is a meaningful SHA1 versus SHA256 determination for encryption
is in the choice of manifest:start-key-generation-name.  This choice is independent of the
encryption used.  It determines whether a 160-bit or a 256-bit password hash is provided to
the PBKDF2 with HMAC-SHA-1 for derivation of the actual encryption keys to be used.  That
hash is a secret and there is some improvement in protecting the encryption when SHA256 is
used.

For ODF 1.0/1.1/1.2 across the board, the common provision is with SHA1 as the default.  The
use of SHA256 and provision of the optional manifest:start-key-generation-name attribute applies
only to ODF 1.2 documents.  

IMPORTANT NOTE: When selecting 256 for ODF 1.2 encryptions (preferably only with the use of
AES in ODF 1.2 documents), the URI <http://www.w3.org/2000/09/xmldsig#sha256> in the
ODF 1.2 specification is INCORRECT.  It should be <http://www.w3.org/2001/04/xmlenc#sha256>.
 See
<https://tools.oasis-open.org/issues/browse/OFFICE-3795>.

If it is thought meaningful to feed an SHA256 into PDBKDF2 instead of starting with an SHA1,
by all means use it for ODF 1.2 documents when AES is the encryption algorithm.  There is
probably no reason to make this an user-selectable option since ODF 1.2 consumers must accept
either case and it is unclear what informed choice is to be expected of users.


 2. OTHER HASH CHOICES DON'T MATTER MUCH FOR ENCRYPTION

There should be no user selection concerning SHA1 versus SHA256 with respect to manifest:checksum.
 The manifest:checksum and manifest:checksum-type provisions are neither security nor privacy
related.  They are to assist in checking whether the decryption is succeeding.  The mandated
cases for consumers only work on the first 1k bytes of the unencrypted file part and the choice
between SHA1-1k and SHA256-1k is insignificant.  Only the SHA1-1k will work across all of
ODF 1.0/1.1/1.2. SHA256-1k must be supported by ODF 1.2 consumers, so it is safe to use when
producing an ODF 1.2-specific AES-256 encryption if desired.  In this particular application
of digital hashes, there is however no advantage of SHA256 over SHA1 and faster is better.
 

Note: Either way, these checksum values disclose information about the *unencrypted* package
file.  In the future, it is desirable to use encryption algorithms that allow manifest:checksum
to be dropped while also verifying the integrity of the encryption/decryption.

 3. SELECTING HASHES FOR PROTECTION

Making a choice between SHA1 and SHA256 for *protections*, not encryptions, is meaningful
only when a document is saved as ODF 1.2.  There is no choice when saving as ODF 1.0/1.1/1.2
for legacy compatibility.  The across-the-board default is SHA1.  Since protections are trivially
defeated without any concern for the digital hash value of the protection key, the only reason
for SHA256 is to make it slightly harder for someone to discover the password from the protection
key.  

Since the protection key value is not a secret and it is easily extracted from the document,
SHA256 versus (160-bit) SHA1 is not a big improvement.  Passwords used for protection keys
are vulnerable to compromise and exploitation.  

See <https://tools.oasis-open.org/version-control/svn/oic/Advisories/00009-ProtectionKeySafety/trunk/description.html>.


 - Dennis


-----Original Message-----
From: Ariel Constenla-Haile [mailto:arielch@apache.org] 
Sent: Friday, December 07, 2012 08:39
To: dev@openoffice.apache.org
Subject: [UX] UI options for document encryption

On Fri, Dec 07, 2012 at 05:19:11PM +0100, Jürgen Schmidt wrote:
> >> The "Encryption GUI" item has not attracted a sponsor. I added
> >> this per the resolution of a very long discussion in BZ [1].
> >> Subsequently, Jürgen wrote an extension to set "SHA256" mode, and
> >> I wrote a macro[2] to toggle the settings; both are still
> >> available.  (I have no idea whether any or many users have used
> >> them.)
> >> 
> >> [1] <https://issues.apache.org/ooo/show_bug.cgi?id=119090#c31>
> >> 
> >> [2] <http://wiki.openoffice.org/wiki/User:TJFrazier/Encryption>
> >> (this page includes text suitable for release notes)
> >> 
> >> If somebody wants to pick up on this, and implement a GUI
> >> (probably in Tools > Options, possibly on the Save and Save As
> >> dialogs), that's wonderful. Lacking all fu for SVN and C++, I
> >> can't volunteer for this.
> > 
> > the best way is to start a new thread asking for UX advice where
> > to include the option. IMHO the Save dialogs are a no-go, the
> > average user will have no idea what this means.
> > 
> > On the other hand, Tools > Options > Load/Save > General has almost
> > no space to add anything else, but may be a new "Encryption"
> > options page is an overhead...
> > 
> 
> Mmh, maybe directly over the "Size optimization ..." checkbox.
> 
> I have thought initially about Tools -> Options -> OpenOffice.org ->
> Security. There should be enough place for a checkbox with some
> explanation.

Changing the subject so that Kevin et al. can find it.


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina


Mime
View raw message