OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] Passwords (Proposal)


Does everyone feel that there's no need to include an algorithm that is
not from the SHA family? If I'm alone in thinking we should include
WHIRLPOOL in case SHA is broken 10 years from now, I won't put up a
fuss.

Best,
Daniel.

On Fri, 2006-08-12 at 11:50 +0100, Michael Brauer - Sun Germany - ham02
- Hamburg wrote:
> 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.
> 
> 
-- 
"I AM in shape. Round IS a shape."

This is a digitally signed message part



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]