OASIS Open Document Format for Office Applications (OpenDocument) TC

Greetings,

I keep running into:

"To avoid saving the password directly into the XML file, only a hash 
value of the password is stored."

But the value, not surprisingly, is "string."

Shouldn't encryption of the password be considered as application specific?

Thus:

Passwords should not be saved without encryption in the XML file. The 
encryption to be used is application specific.

Which raises the interesting issue of how one indicates what 
hash/encryption function was used?

I am assuming that simply because one ODF comformant application uses a 
particular hash function, there is no gurantee that another will use the 
same function.

Hope everyone is having a great day!

Patrick

-- 
Patrick Durusau
Patrick@Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work! 

On Tue Nov 28 2006, Patrick Durusau wrote:
> Shouldn't encryption of the password be considered as application specific?

This would simply kill interoperability. Why don't we standardize the hash function instead?

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

On Tue, 2006-28-11 at 10:08 +0100, David Faure wrote:
> On Tue Nov 28 2006, Patrick Durusau wrote:
> > Shouldn't encryption of the password be considered as application specific?
> 
> This would simply kill interoperability. Why don't we standardize the hash function instead?

Or provide a short list of acceptable hash functions. For example: SHA1,
SHA256 and SHA512.

I'm a tad hesitant about SHA1 because it's been "broken", but only for
finding collisions:

http://www.schneier.com/blog/archives/2005/02/sha1_broken.html

So, you shouldn't use SHA1 for digital signatures, but AFAICT it's still
perfectly good for encryption and password purposes where you are not
looking for collisions but a pre-image.

The reason I suggest a list is that not everyone might want to use
SHA512 for their passwords, as it's over-kill, but we shouldn't disallow
people who do want to use SHA512.

Cheers,
Daniel.
-- 
"I AM in shape. Round IS a shape."

David,

David Faure wrote:

>On Tue Nov 28 2006, Patrick Durusau wrote:
>  
>
>>Shouldn't encryption of the password be considered as application specific?
>>    
>>
>
>This would simply kill interoperability. Why don't we standardize the hash function instead?
>
>  
>
Sure, but we did not even specify a choice of hash functions in the 
current version.

So, specifying what must/should be supported will enhance 
interoperability but would be more restrictive than our prior statements 
on this issue.

Does anyone know if the list of hash functions posted by Florian 
(thanks!) would be considered sufficient by government agencies? Or common?

Hope everyone is having a great day!

Patrick

-- 
Patrick Durusau
Patrick@Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work! 

On Tue, 2006-28-11 at 06:29 -0500, Patrick Durusau wrote:
> Does anyone know if the list of hash functions posted by Florian 
> (thanks!) would be considered sufficient by government agencies? Or common?

I'm no expert, but I think that for the USA we are looking at NIST (ie.
SHA1, SHA256, SHA384, SHA512) and for Europe we are looking at NESSIE
(i.e. WHIRLPOOL, SHA256, SHA384, SHA512).

My vote is for the NESSIE list, while making support for SHA256 and
WHIRLPOOL mandatory.

-- 
"I AM in shape. Round IS a shape."

In the United States government use,
you want to be on the FIPS (Federal Information Processing Standards) list
of acceptable algorithms.  From an open standard perspective you would
also want to have at least one algorithm which is unencumbered by patents.

According to http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf
the FIPS hash algorithms are: SHA-1, SHA-256, SHA-384,  and SHA-512

-Rob

Patrick Durusau <patrick@durusau.net> wrote
on 11/28/2006 06:29:31 AM:


> David,

>

> David Faure wrote:

>

> >On Tue Nov 28 2006, Patrick Durusau wrote:

> >  

> >

> >>Shouldn't encryption of the password be considered as application
specific?

> >>    

> >>

> >

> >This would simply kill interoperability. Why don't we standardize

> the hash function instead?

> >

> >  

> >

> Sure, but we did not even specify a choice of hash functions in the

> current version.

>

> So, specifying what must/should be supported will enhance

> interoperability but would be more restrictive than our prior statements

> on this issue.

>

> Does anyone know if the list of hash functions posted by Florian

> (thanks!) would be considered sufficient by government agencies? Or
common?

>

> Hope everyone is having a great day!

>

> Patrick

>

> --

> Patrick Durusau

> Patrick@Durusau.net

> Chair, V1 - Text Processing: Office and Publishing Systems Interface

> Co-Editor, ISO 13250, Topic Maps -- Reference Model

> Member, Text Encoding Initiative Board of Directors, 2003-2005

>

> Topic Maps: Human, not artificial, intelligence at work!

>

>