openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <>
Subject Re: [UX] UI options for document encryption
Date Fri, 04 Jan 2013 11:43:30 GMT

excuse my top posting. I generally agree to Dennis that we can do much
more here and make it better but what Dennis have described is too much
effort for me at the moment and I don't have time for it.

Nevertheless would I like add a simple way for users to switch between
the old and the new encryption algorithm more easy. Currently they can
use my extension [1] or can do it on their own to enable AES256.

I can think of a simple checkbox in the Load/Save - > General section of
the options dialog, see [2]. I don't believe that users will switch very
often between the 2 alternatives and will decide ones and globally.

Dennis described a much more flexible approach but also much more work.
And until now, no volunteer picked up this item.

My proposal is just an idea and the wording can be probably improved.


The remaining question is if we can find support for this simplified
solution and what should be the default in 4.0?


On 12/7/12 8:40 PM, Dennis E. Hamilton wrote:
> I've given some of the technical considerations behind security and protection provisions
for ODF 1.0/1.1/1.2 documents.  
> I think for usability and UX, there are the following considerations:
>  1. Choices offered to users are ones for which informed decisions can be made and there
is clear guidance on the consequences of the choices.  
>  2. The Choices concerning encryption of documents (those associated with "Save with
Password") that are security and privacy related need to be clearly separated from those that
are unrelated to both security and privacy (i.e., the various protection options).
>  3. Since the use of message digests (SHA1, SHA256, and others that are allowed in ODF
1.2 documents) is employed in both protection and encryption, there should be no options about
the message digests used.  The user choices should be with respect to the actual situations.

>     1.1 Currently on Save with Password (where folks know to find it already), there
should be nothing but Save with Password dealt with on the dialog that comes up when a Save
>     1.2 The choice should be between
>          o ODF 1.0/1.0/1.2 Compatible (Blowfish)
>          o ODF 1.2 Exclusive (AES256)
>     If the document is being saved as ODF 1.0/1.1, no choice should be offered. 
>     This is on the same panel that requests a password (though it might be preset).
>     There should be a way to confirm/cancel encryption separate from cancelling the save.
>     1.3  There can be a default radio-button preset when saving as ODF 1.2 [extended].
>     The default might be a configuration option for the ODF 1.2 case, but the choice
>     still be offered.  (Forcing an user to make a major configuration decision for occasional
>     variations is undesirable.)
>     1.4 When enterprise configuration/customization is provided for, there might be ways
to force
>     the choice in 1.2 as well as limiting Save As ... format choices.  I am assuming
that is 
>     out-of-scope for this simple public user consideration.
>     1.5 It might be desirable to also have provisions for encryption in the Document
>     dialog, on its own tab there.  (Protections should be on a separate tab.)  It can
then be 
>     possible to set and to reset encryption, and a password could be elicited on setting,
>     in that case it should still be cancellable at Save or Save As ... time.  (See above.)
>     [The principle is to not take users down blind alleys.]
>     1.6 NO MATTER WHAT: The warnings about the document not being recoverable if the
password is
>     lost or forgotten need to be prominent in all places where a choice is offered in
the matter.
>     2.1 Protection dialogs already exist in various places.  Some whole-document protections
are not in the same places.  There are UX considerations around when the protections are set
and when they are implemented in the document that is produced.  Some can be set any time
while editing the document and have immediate effect.  Some would prevent further editing
so tend to not be set until the document is saved.  This requires more cases to be worked
>     2.2 Generally, the choice is between ODF 1.0/1.1/1.2 compatibility and ODF 1.2 exclusive
functionality.  The difference in the SHA used is not a meaningful consequence for the user's
informed choice.  
>     2.3 The current offering of document-level protections via an "Additional Options"
button on the Save with Protection dialog has to move.  It's also done there and elsewhere
in a confusing way.
>     2.4 NO MATTER WHAT: Protections must be disavowed as security and integrity features.
 Users should be informed, in some manner, that protections are easily defeated and are mainly
for safeguarding against accidental modifications.  In particular, users must be cautioned
that the password used is not itself protected in a secure way and a valuable password should
not be reused for this purpose.
>  - Dennis    
> -----Original Message-----
> From: Dennis E. Hamilton [] 
> Sent: Friday, December 07, 2012 10:26
> To:
> Subject: RE: [UX] UI options for document encryption
> Please see <> in addressing
security vs protection in the UX also.
> 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.  
> 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
> 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 <>
in the ODF 1.2 specification is INCORRECT.  It should be <>.
> <>.
> 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.
> 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.
> 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
> 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 <>.
>  - Dennis
> -----Original Message-----
> From: Ariel Constenla-Haile [] 
> Sent: Friday, December 07, 2012 08:39
> To:
> 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] <>
>>>> [2] <>
>>>> (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 -> ->
>> Security. There should be enough place for a checkbox with some
>> explanation.
> Changing the subject so that Kevin et al. can find it.
> Regards

View raw message