Re: E / Python interoperability suggestions?

On Sep 1, 2010, at 21:15, Bill Frantz wrote:

> Assuming we want to adopt the TLS protocol and implement it in
> E, we will need a bunch of crypto primitives. From memory they are:
>
>    MD5 + SHA1 - For the TLS pseudo random function
>    A digital signature algorithm - currently DSA (uses SHA1)
>    A Diffie-Hellman implementation - Currently in Java using a
> prime field
>    A symmetric encryption algorithm - Currently triple DES
...
> The above gives us the maximum portability. Any E implementation
> which can provide the basic network listen, call, send, and
> receive automatically has E communication.

I had assumed that TLS was a canned protocol we could use outside  
libraries to implement; I seem to recall old discussion about 'the  
only reason we can't adopt TLS is that the common library/ies doesn't  
let us read the key fingerprint' which then became false.

I'm also skeptical about implementing crypto algorithms *in* E, simply  
because of the speed cost. We don't have E implementations that can  
compile arithmetic to machine code yet. (Though E-on-CL is the closest  
to being in a position to do that; it just needs to be able to  
recognize arithmetic on integers and compile into CL arithmetic  
operators, and then if we're running on SBCL we can get machine- 
register arithmetic for free.)

> An alternative is to link to a library like OpenSSL. I'll let
> others figure out whether that will be easy for their implementations.

Well, I assumed that for example in the CL case we would use Ironclad <http://method-combination.net/lisp/ironclad/ 
 > as far as possible. This keeps us in the area of portable CL  
(rather than being affected by CL implementation *AND* OS varieties).

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>