[e-lang] E / Python interoperability suggestions?
frantz at pwpconsult.com
Wed Sep 1 18:15:19 PDT 2010
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
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
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
www.pwpconsult.com | buffer overruns. | Los Gatos,
More information about the e-lang