You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Jürgen Schmidt <jo...@gmail.com> on 2013/01/04 12:43:30 UTC
Re: [UX] UI options for document encryption
Hi,
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.
[1]
http://people.apache.org/~jsc/extensions/ODF12-Default-encryption-AES256-cbc.oxt
[2] http://people.apache.org/~jsc/test/UX_document_encryption_v1.png
The remaining question is if we can find support for this simplified
solution and what should be the default in 4.0?
Juergen
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.
>
> SUGGESTIONS
>
> 1. FOR ENCRYPTION
>
> 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 starts.
>
> 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 should
> 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 Properties
> 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, although
> 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. FOR PROTECTION
>
> 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 out.
>
> 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 [mailto:dennis.hamilton@acm.org]
> Sent: Friday, December 07, 2012 10:26
> To: dev@openoffice.apache.org
> Subject: RE: [UX] UI options for document encryption
>
> 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
>