Jason Dufair <jase at dufair.org> wrote:

> I just thought I'd mention that with my nascent OpenSSL plugin, I brought
> the execution of my app (which decrypts an AES-encrypted file) down from
> 80-90 seconds to 0.7-1.4 seconds, 60% of which is file I/O.

Good news.

> It looks like dlopen() may not be the panacea I'd hoped it would be
> since it's apparently not supported on Mac OS X.  But cross-platform
> maintenance of the OpenSSL plugin via header files and linking to dll/so
> files should be very minimal.
That's hardly portable - some of us have utterly different mechanisms
for this sort of stuff.

Consider something like:-
primitiveAESEncryptCBC: plainText ciphertext: cipherText key: aKey iv:
anInitializationVector
"Encrypt aByteArray using the AES (Rijndael) algorithm in CBC mode"

	self cCode: '' inSmalltalk: [^nil].  "tpr add return
for trivial support of simulator"

	self primitive: 'primitiveAESEncryptCBC' parameters: #(#ByteArray #ByteArray #ByteArray #ByteArray).
	self encrypt: plaintext to: ciphertext key: aKey iv: anInitthingy

note that encrypttokeyiv() will be generated by the CCodeGen and then
implement it in a platform specific file. You could also implement
encrypt:to:key:iv: in a simulator class for the benefit of
InterpreterSimulator users, dropping the ^nil at the top.

In each supported platform's file you then deal with its quirks. I
would imagine the windows version would be a trivial transposing of the
original contents of your prim?

As long as a platform can do openSSL compatible munging based on the
four parameters, you're ok. Oh, consider implementing initialiseModule
in a similar manner such that each platform can do what it needs. See
various othe plugins for examples.

 
> 
> Since my code will replace some (perhaps eventually all) of the
> functionality in the Cryptography package, does anyone have any
> suggestions WRT namespace issues?  Package names and Class names?  I
> wanted to keep the interfaces the same as the existing package to the
> point where my package could be a drop-in replacement, but my interface
> ends up being a level higher than what's in the Cryptography package
> (and the lower level stuff is down in the primitive itself), so that
> plan won't work after all.
Bridges. Have the high level stuff talk to a translator class that can
pass off to openSSL or whatever is already there. Choose the translator
class by appropriate means at runtime.


tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: WRTJ: Who Reads This Junk?