Using different hash algorithm in purple_util_get_image_checksum()

Marcus Lundblad ml at
Thu Jul 2 07:13:24 EDT 2009

tis 2009-06-30 klockan 14:25 -0700 skrev Mark Doliner:
> The purple_util_get_image_checksum() function in libpurple/util.c
> currently uses SHA-1 to generate a checksum for a chunk of image data.
>  SHA-1 is a cryptographic hash function, which means it's hard for
> someone to engineer a chunk of data that matches a given hash.  It
> also means it's slow.
> Do we need to be using a cryptographic hash function here?  This hash
> function is one of the more expensive parts of libpurple.  I think
> it's called once for each buddy icon we receive.  Adler-32 is much
> faster when you're not concerned about security (it's maybe 8 times
> faster than SHA-1).  zlib contains an Adler-32 implementation.  I
> think GLib's g_string_hash() function is also pretty fast (but not as
> fast as Adler-32 when hashing image data).  I haven't really
> investigated what problems we would have switching hash functions... I
> think we would have to migrate or purge buddy icons from
> ~/.purple/icons/, because the icon filename is the hash.  And there
> might be other problems.
If we are going to change how hashing of icons is done, maybe we should
allow the hashing algorithm to be "encoded" into the resulting file
names in the icon cache?
This way, custom smileys could be store in there as well. As it is today
the function adding a custom smiley to a conversation takes two
arguments, "type" and "hash" (taken from my memory). It returns a
boolean telling if the conversation needs the data. Currently it will
return TRUE. I suppose this could be enhanced to take advantage of a
hash type-aware cache.
Currenly the type is set to "sha1" in the MSN prpl. In XMPP I have taken
the CID value from the BoB object and set the type to "cid", although
the recommended construction of CIDs in XEP-0231 is of the form algo
+hash at
So potentially it could parse out the hash type and hash value if the
CID is of this form, maybe.
Though, I guess this would require quite extensive changes to

> But, uh, how to people feel about this change?
> -Mark
> _______________________________________________
> Devel mailing list
> Devel at

More information about the Devel mailing list