[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Passwords (Proposal)
Hi all, based on the discussions we had, I would suggest that we extend the description of of the protection-key attributes as follows: 4.4.3:Protected section [To avoid saving the password directly into the XML file, only a hash value of the password is stored.] The hash value is calculated using the algorithm specified by the text:protection-key-digest-algorithm attribute. It takes the values described in §5.7 of [xmlenc-core]. Applications *shall* support SHA1, which is the default, and *should* support SHA256. They *may* support other algorithms described in §5.7 of [xmlenc-core]. <define name="sectionAttr" combine="interleave"> ... <optional> <attribute name="text:protection-key-digest-algorithm" a:defaultValue="http://www.w3.org/2000/09/xmldsig#sha1"> <ref name="anyURI"/> </attribute> </optional> </define> The description of other protection-key attributes would be extended in the same way. Best regards Michael Daniel Carrera wrote: > On Tue, 2006-28-11 at 14:04 -0500, Patrick Durusau wrote: >> Not exactly. >> >> If the file associations are not editable by the user, limiting opening >> of the file to the use of an ODF compliant application and they are >> denied access to a DOS command window (with edit or something similar) >> it can be made relatively secure. > > Well, it seems unlikely that a user would be in an environment that lets > them read the XML contents but not edit them. > > But I can think of another reason to use hash though: To protect the > password itself, in the event that the document owner chooses to use the > same password elsewhere (which is common). > > So, we want a hash that is pre-image resistant. SHA1 qualifies for now, > but I do note that RSA expects to see pre-image attacks in the next 5-10 > years. Are we satisfied with that or should we ask for something higher? > > Maybe we can take a middle position and say that SHA1 is allowed but we > recommend applications to move to something else in the future. The spec > could say something like this: > > -------- > The hash can be any of: SHA1, SHA-256, SHA-512 and WHIRLPOOL. The > committee notes that SHA1 is included for compatibility with current > applications but recommends moving to one of the other algorithms in the > coming years. > -------- > > I think that's a reasonable balance. It doesn't cause immediate hassle > for developers. > > But what will we do, say, 8 years from now, when SHA1 is no longer > considered acceptable? Do we change the spec to disallow SHA1? If so, > then some old documents will become invalid. This is a general problem > with any hash or encryption algorithm; one day Blowfish might be broken > and we may have to choose a different algorithm. > > Best, > Daniel. -- Michael Brauer, Technical Architect Software Engineering StarOffice/OpenOffice.org Sun Microsystems GmbH Nagelsweg 55 D-20097 Hamburg, Germany michael.brauer@sun.com http://sun.com/staroffice +49 40 23646 500 http://blogs.sun.com/GullFOSS
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]