Re: [RFC] Horde_Cipher -> Crypt_Cipher

I thought it was about time I said something around here, I'm the author of most of the Horde_Cipher package. Davey wrote:

Having had a look at Horde_Cipher, and knowing it would be useful in my XML_Encrypt package, I would like some thoughts on releasing the current version of Horde_Cipher as Crypt_Cipher in PEAR. AFAICT it has no Horde dependencies and follows PEAR CS et al; I am happy for the rename to happen. I will not support the code if it is branched into the PEAR CVS.

So we have two conflicts: Firstly (and foremost IMO) we have Crypt_RC4 already, what should we do about the redundancy? Horde_Cipher currently uses Crypt_RC4 to do it's RC4 encryption. Either merge this class into the new package or have it as a dependency.

Crypt_Cipher - Unified API for *ONLY* Encryption Methods Crypt_Hash - Unified API *ONLY* for Hashing Methods I would support this, it makes sense to only have two packages one for ciphers and one for hashs. No point in a package for each hash or each cipher.

Anyways, just an RFC, I don't mind porting Horde_Cipher over in the ways I've mentioned. Um, class name change is the only thing mentioned so far.

One last thing, if this is done, should the various encryption drivers provided with Horde_Cipher also be released as standalone packages so that they can be used on their own like the current Crypt_* packages aswell as with the Crypt_Cipher package... Not keen on this at all. Completly pointless. All the Horde_Cipher ciphers are blockmode ciphers. They all only encrypt 8 byte inputs. Without the rest of the Horde_Cipher block classes, all you'll ever be able to do is encrypt 8 byte pieces of data. The Blockmode classes provide a way of encrypting any length inputs using the blockmode ciphers.

If anyone is using a cipher independantly, they'd have to (re)implement the blocking them selves. Pointless when it allready exists.

If that happens, it would *probably* be easiest to actually just write my own abstraction class atop the single packages?

- Davey

I've spent the last 2 days talking on the Horde ML and also just looking around and would like to talk some more about this and get more feedback. Here is what I am now thinking: We have two choice; 1) Split up Horde_Cipher into several seperate packages with redundancy due to the need for blocking Don't look to me for support here.

2) Keep Horde_Cipher together and move the other packages into it. Only Crypt_RC4 would'could be moved.

Now, with the first, as mentioned from what the Horde ML has said, the blocking needed by each package would cause redundancy, so I though that perhaps we could have a Crypt_Cipher_Base that contains all the blocking and other code that would be redundant, then the user just adds Crypt_* as they want. On that note, *what* does Crypt_CBC do? I kinda picked up it might be a package that does the blocking stuff, could this be used by the Horde stuff if so? No, there is allready a cipher block chaining (CBC) class in horde_cipher (it's only 21 lines of code). Crypt_CBC wouldn't be able to be used, completely different api and not appropriate to change it.

Dave: Are you still working on Crypt_RC4? I've heard that you are not, and if not would mind deprecating it in favour of the bundle RC4 stuff in Horde_Cipher? There is no RC4 implementation in Horde_Cipher. Horde_Cipher uses this code.

Personally, I'd like to see each of the Horde_Cipher 'drivers' become standalone packages with a central blocking package, this means that when you only *need* DES, or blowfish, thats all you need to have. I Not cool. I would not like to see everything split up into 6 packages. If you have the cipher class installed, you'd expect to have all the ciphers come with it. Who installs mcrypt with only one cipher? Who installed the DB package and then deleted all the ones they weren't going to use? I don't think there'd be much support for splitting DB into 14 packages.

Do all the packages already have a pretty similar API? I know this is No offence, but did you have a look?

Just to clarify the question as I have a tendency to convolute such issues: We should have a abstraction class to create a unified API for both Cipher and Hashing algorithms, which also allows for using mcrypt/mhash where available instead. We have to decide the following: A) Should the current Crypt_* packages be deprecated as stand-alones and instead be distributed as drivers for Crypt_Cipher and Crypt_Hash Okay...

OR B) Should the current drivers in Horde_Crypt be moved to stand-alone packages with redundant blocking code and just have the API on top? No.

OR C) Should the current drives in Horde_Crypt be moved to stand-alone packages with a base package providing the blocking code, again the API just sits on top No.

Davey, sorry if you found any of my comments harse, I'm just not keen to see my code broken up by someone that hasn't taken the time to understand how it works yet. Just a bit about the Horde_Cipher code, for those who haven't had a look at it. It's a pretty simple to use class. All encryption is currently doing in php as i'm on wind32 and mcrypt isn't an option. Adding the code to use mcrypt if available wouldn't be hard. Here's an example of how it can be used:

    $cipher = &Horde_Cipher::factory('blowfish');
    $cipher->setBlockMode('ofb64');
    $cipher->setKey($key);
    $encrypted = $cipher->encrypt($message);
    $decrypted = $cipher->decrypt($encrypted);

Here's the docs for the class:

    http://www.graftonhall.co.nz/reference/cipher/

- Mike :-)