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

Hi Daniel, all,

actually, the "password" we are talking about do not belong to a 
security feature like digital signatures or encryption, but are only 
passwords that an office application user interface may request before a 
user may remove the write protection of a text section or table.

The hash values we are talking about are only used to encode the 
password itself.

For this reason, I think it should be sufficient to specify a single 
hash algorithm that shall be used. Since we are using SHA1 already 
inside the packages, and since SHA1 is used in practice by 
OpenOffice.org, I would like to propose that we specify that SHA1 is 
used to calculate the hash value. This seems also to be in alignment 
with the W3C xml-enc requirements that Florian has posted.

If we want to extend this to other algorithms, then we need an 
additional attribute to specify the algorithm that is used to encode 
that hash value. Given the purpose of the password attributes in 
question, I personally don't think we need that. But if we want to 
support additional algorithms, then I agree to Florian's suggestion to 
follow the XML Encryption specification.

There is only exception, and this is the password attribute specified in 
section 8.8.3 Source Service. This password is checked by the external 
components that this section describes itself. The ODF implementation 
therefore has no control how the password is encoded. The attribute 
description therefore seems to be correct.

Best regards


Daniel Carrera wrote:
> On Tue, 2006-28-11 at 11:11 +0000, Daniel Carrera wrote:
>> Yes, that would be good. We can say that SHA1, SHA256, SHA512 and
>> RIPMEND-160 are all ok (list taken from xmlenc), but all implementations
>> must support at least SHA256 but preferably all.
> I know this is moving further away from Florian's list, but I think we
> should also include WHIRLPOOL. There are good reasons for this:
> 1) SHA and RIPMEND are based on the same design principles, the same as
> MD4/MD5, and hashes from this family are continuously being broken (MD4,
> MD5, SHA-0, SHA-1 and the original RIPMEND). Some worry that there is a
> fundamental design problem (see Bruce Schneier) and we need a completely
> different algorithm.
> WHIRLPOOL is the only popular hash I know of that is of a different
> design.
> 2) WHIRLPOOL is an ISO standard (ISO/IEC 10118-3), is un-patented, is
> believed to be secure, and it has been recommended by the NESSIE
> project.
> NESSIE = New European Schemes for Signatures, Integrity and Encryption
> http://en.wikipedia.org/wiki/NESSIE
> I notice that NESSIE did _not_ recommend SHA-1 at all, but only the
> later variants.
> In fact, why don't we use the NESSIE list instead of xmlenc? NESSIE's
> list is WHIRLPOOL, SHA-256, SHA-384 and SHA-512.
> I would feel more comfortable using this list than the other one. And we
> could say that applications must support at least WHIRLPOOL and SHA-256.
> What do you think?
> Cheers,
> Daniel.

Michael Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

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