[e-lang] E / Python interoperability suggestions?

[Bill Frantz]

On 9/1/10 at 4:30 PM, kpreid at switchb.org (Kevin Reid) wrote:

>On Sep 1, 2010, at 16:56, Bill Frantz wrote:
>
>>On 9/1/10 at 5:25 AM, kpreid at switchb.org (Kevin Reid) wrote:
>>
>>>E-on-Java's CapTP still uses TLS. In my two new CapTP
>>>implementations, no VatTP layer exists yet.
>>
>>Did the change from VatTP protocol to TLS happen, or is the 
>>protocol still the old VatTP protocol?
>
>It did not.
>
>I see the path as being that we write a new VatTP layer in E to 
>go with CapTP in E, then ditch the Java CapTP and Java 
>custom-protocol VatTP at the same time.
>
>(VatTP itself still exists beyond TLS, as TLS does not address:
>* maintaining the single-connection-per-pair-of-vats invariant.
>* denoting message boundaries on a connection.
>)

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

Since this protocol won't be compatible with VatTP, we probably 
want to move into the modern age of algorithms, which brings up 
the question of, "How paranoid are we?"

We currently use the 1K versions of DSA and Diffie-Hellman. Many 
people think these are too small for long-term future security. 
We can get a CPU performance increase by moving to AES-128, 
since DES is not well-suited to software implementation, but we 
need to think about using the 192 or 256 versions. (If I 
remember correctly, 128 is OK for US data classified as 
"secret", but you need at least 192 for "top secret" data.)

NIST and NSA are moving all their public key algorithms to 
elliptic curves (EC). EC is a bit of a patent minefield, but I 
think there are some RFCs which specify curves that may be used 
by open software. The advantage of EC is smaller keys and faster calculation.

Once we've gotten the algorithm issues settled, then "all" we 
have to do is write a TLS implementation. The temptation will be 
to not do things that are "MUST" in the standard because we 
don't need them, or don't know how they apply. (Remember, the 
TLS people like certificate authorities.)

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.

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


>If I recall correctly, you're the original VatTP/crypto guy; 
>would you be interested in contributing any design or 
>implementation work?

I can certainly work on the design.


>And would you mind resending your message to the list? I feel 
>that discussion in an open-source project should occur in 
>public absent reasons not to.

I agree. The only reason for a private message was, if the 
conversion had already occurred, it would save noise on the list.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | gets() remains as a monument | Periwinkle
(408)356-8506      | to C's continuing support of | 16345 
Englewood Ave
www.pwpconsult.com | buffer overruns.             | Los Gatos, 
CA 95032