[dev] Fwd: [PEAR-DEV] Re: [RFC] Horde_Cipher -> Crypt_Cipher

[Jan Schneider]

----- Weitergeleitete Nachricht von davey at php.net -----
    Datum: Sun, 27 Jul 2003 15:02:09 +0100
    Von: Davey <davey at php.net>
Antwort an: Davey <davey at php.net>
 Betreff: [PEAR-DEV] Re: [RFC] Horde_Cipher -> Crypt_Cipher
      An: pear-dev at lists.php.net

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 ;)


--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



----- Ende der weitergeleiteten Nachricht -----


Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft