W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2011

Re: Proposal for hash functions in SPARQL 1.1

From: Steve Harris <steve.harris@garlik.com>
Date: Fri, 30 Sep 2011 11:18:45 +0100
Cc: public-rdf-dawg@w3.org
Message-Id: <5BAF76CD-C2A8-4252-A81A-0CED6AC08785@garlik.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
On 2011-09-29, at 17:30, Andy Seaborne wrote:
> 
>>> Proposal 5:
>>> MD5
>>> SHA1
>>> SHA256
>>> SHA512
>>> SHA384
>>> SHA512
>>> 
>>> (i.e. remove SHA224, but that's the problmeatic one for the commenter
>>> (Jeen) because it's not in the core Java runtime).
>> 
>> You also include SHA512 twice, making the list look longer!  :-)
> 
> Two independent implementations, just to be sure.
> 
>> Also, I was advised against including MD5 -- as the earlier xmldsig
>> advises -- because of known security problems with it.  I guess the
>> theory is that it's important to steer people away from technology that
>> looks secure but isn't.   (The counter-argument is that some people
>> still use it.  But maybe should let that be entirely on them.)
> 
> Yes - it's not recommended for weak for SSL certificates or digital signatures (hence xmldsig).
> 
> MD5 has it's place as for error-checking:
> 
> http://en.wikipedia.org/wiki/MD5#Applications

Yes, agreed, and it's still widely used.

We also use it to create persistent, but non-human readable URIs where security isn't an issue, SHA1 is significantly longer.

We do it in the application layer, but you could do it in SPARQL 1.1:
   URI(CONCAT("http://garlik.com/id/", MD5(CONCAT(?email, " ", ?date))))
or similar

Come to think of it, a UUID() function might be useful too, but that can wait for SPARQL 1.2 :)

- Steve

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Friday, 30 September 2011 10:19:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:46 GMT