Re: [RFC] Horde_Cipher -> Crypt_Cipher

Davey wrote:

Hey, 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; The main reason I want feedback is this: Horde_Cipher is just an API for multiple encryption algorithms (blowfish, des, cast128, rc2, rc4 and also in blockmode some others stuff). So we have two conflicts: Firstly (and foremost IMO) we have Crypt_RC4 already, what should we do about the redundancy? Secondly, the current Crypt_* cipher stuff (RC4, CBC, XTEA) are single stand-alone packages, I can see about modifying Horde_Crypt to a) use the current Crypt_RC4 instead of theirs and b) and also add the others to it? Whilst looking up the names of the various Crypt_* packages I have come across Crypt_Crypt this seems to be going no-where... (please correct me if it is, but from "I should have something for you guys to look at tonight" post on 15th February 2003 to pear-dev theres been no releases) . I would like to propose the following: Ditch Crypt_Crypt (the name is a bit ambiguous because of the fact Crypt_* contains encryption and hashing packages. And do this: Crypt_Cipher - Unified API for *ONLY* Encryption Methods Crypt_Hash - Unified API *ONLY* for Hashing Methods This seems much more... verbose IMO. Anyways, just an RFC, I don't mind porting Horde_Cipher over in the ways I've mentioned. 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... 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 2) Keep Horde_Cipher together and move the other packages into it. 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? With the second, we need to decide what would happen, Horde ML mentioned that doing this would deprecate Crypt_CBC (though not knowing what it does, I'm not sure why this is). I'm gonna write specific stuff to each maintainer below to answer (or anyone else who is qualified): Colin: What does CBC do? if it is blocking, can I use it how I'd like? Does it have a place in an all-in-one Crypt_Cipher/Hash package? 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? Jeroen: What would you like to happen with your package? Michael: Would Crypt_CHAP fit in Crypt_Cipher? is it hashing or encrypting? From what I know about CHAP its has a pretty specific use and wouldn't be used in an environment which would require more than one type of hasing/encryption and therefore Abstraction should not be used. And to all maintainers, you know your code and presumably you know the algorithms and stuff that lie beneath them whereas I do not, so would you be willing to maintain your packages as drivers for Crypt_Cipher/Hash? 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 don't want to use an entire abstraction class with Auth_HMAC for example, I *know* I'm only going to be using HMAC and nothing else. I think once the current package owners have answered the questions above, we'll have a clearer idea of what wants doing, and then I'll just get on and do it. Do all the packages already have a pretty similar API? I know this is the policy with other groups of packages such as these... if not, would your maintainers be willing to break BC and release a new major version (as has been decreed at the PEAR meeting) to bring the Crypt_* category into a more unified system anyways.... Anyone else, please feel free to comment! 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 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? 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 - Davey p.s. To all maintainers I have CC:'ed, don't forget reply all ;)