adding new libpurple ciphers - HMAC and TripleDES/CBC

[Ethan Blanton]

Elliott Sales de Andrade spake unto us the following wisdom:
> So, I've been looking at implementing MSNP15 (from MSNPiki [1] and
> OpenRCE [2]), and I managed to get a version running that logs on
> correctly. At the moment, it's pretty hackish, but fortunately, there
> are minimal changes that are required. Anyway, first things first are
> to fix those hacks.

I can't speak particularly to MSNP15, although I'm glad you're looking
at it, but I do have some comments on the crypto side of things.  Gary
wrote our crypto API, so I'll also leave the details of that to him.

> The first thing we need are two additions to the available ciphers, as
> well as some updates to the existing ciphers.
> 
> Firstly, there is keyed-Hash Message Authentication Code (HMAC) [3].
> It is fairly simple to implement. There are a few questions I have
> with this, though. HMAC can be used with several different hashing
> functions. In order to implement this,  I was thinking of having just
> one "hmac" cipher, with an option (via
> purple_cipher_context_set_option) to select an underlying cipher
> (would a PurpleCipher do?). Secondly, HMAC needs to know the block
> size of the underlying hash function. I see functions to find the key
> size and the salt size, but I don't think the block size is currently
> available. Would we just add a function to the padding?
> 
> Secondly, there is TripleDES [4]. This is mostly based on DES. What's
> needed is to add support for decryption in the DES cipher. I'm not
> sure why this wasn't implemented, since it only requires specifying a
> 1 the mode parameter of des_ecb_crypt. Once this is added, TripleDES
> is just a matter of chaining together encryption, decryption, and
> encryption. As a side note, I was wondering why DES encryption returns
> 0? If it returned TRUE, this would match the digests. Also, is there
> any reason the output length parameter is not checked for being NULL?

If you want to implement DES encrypt, that's simple to add.  We can
add it in any release, as it is a query-able feature.

> Finally, there is adding a Cipher-block chaining (CBC) [5] mode to
> TripleDES (and regular DES may benefit from this as well). Again, this
> is a simple thing to implement. The only question I have is how to
> specify it. I'm thinking of just adding an option again. Probably an
> enum or some defines will do here.

The block encryption modes can be implemented entirely on top of the
API we have now.  Most encryption libraries likely have more optimal
implementations than would be created by such a layering, but as far
as *functionality*, we have all that you would need, as is.  If you
want to create a layer for this, we would be glad to apply it; you
probably want to talk to Gary about how to proceed with it.  If you
want to get clever, you could probably create a mechanism which used a
generic implementation for ciphers which didn't have an optimized
implementation, and the latter for those which did.

> Anyway, I'll submit some patches for this ASAP after I get some
> feedback here. Of course, I don't really know a lot about these
> ciphers, and I learnt most of it off of wikipedia, so if someone knows
> better, feel free to suggest some optimizations or things to do
> better.

I have not read the wikipedia entries on these encryption algorithms,
but I generally find wikipedia to be less than a) correct, and b)
complete.  I recommend the Handbook of Applied Cryptography [1] as an
accurate free resource.  It is also available in print form.

Ethan

[1] http://www.cacr.math.uwaterloo.ca/hac/

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20071202/3f9735a5/attachment.sig>