That's would be ideal.
I've never worked with Crypto++ before or with heavy duty crypto libraries
in general, and I was kind of delegated to take on the project at work, so
I'm kind of stuck. And the only reason I started the project up was because
libmcrypt/libmhash don't work too well under Windows, and we needed
something as portable as possible.
I haven't written up any plans for how the extension would work, but I'd
like to keep it as simple as possible. I'm just kind of tooling around
right now, but basically, it's just the Crypto++ API wrapped in a couple of
extra classes, which will then provide interfaces to PHP's C code. Right
now, you can code something like this in C++ using the wrapper classes:
JBlowfish myBlowfish;
/* create an IV with a length of 128 random characters from /dev/urandom,
or the standard rand() function if your OS doesn't support urandom /*
myBlowfish.setIV(new JIV(128));
myBlowfish.setKeylength(16);
myBlowfish.setKey("this is the secret key");
myBlowfish.setPlaintext("this is secret data to encrypt");
myBlowfish.setMode(JCRYPTO_MODE_CBC);
myBlowfish.encrypt();
cout << "Ciphertext: " << myBlowfish.getCiphertext() << endl;
To decrypt the steps are similar. Of course, there are various constructors
to cut down on the calls to member functions and stuff. (As for the "J"
prefixed to everything, like JIV or JBlowfish, that was mostly to avoid
confusion -- is this Crypto++'s Blowfish class, or the wrappers?) I picture
a similar, OO interface from PHP-land.
Writing the interface from C to C++ is going to be a major biatch. Then
there's writing all of the other wrappers for the various ciphers (so far
I've only done three, and just for ECB and various CBC modes).
I can't make any promises, but hopefully I'll be able to get something
going over the next few weeks.
J
[EMAIL PROTECTED] wrote:
> On Tue, 5 Mar 2002, Joseph Tate wrote:
>
>> Well, J Smith has mentioned Crypto++. I haven't looked into it, but that
>> sounds like a good little module as a substitute for mcrypt. If he truly
>> is working on a php extension using it, then it's purely acedemic to add
>> it to your module.
>
> IMO, if there will be an interface to crypto++ it should be merged into
> the current mcrypt one, forming together a new combined module. (Just like
> Sterling is trying to do for XSLT).
>
> Derick
>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
