On Monday, 5 May 2014 at 14:59:13 UTC, Etienne wrote:
On 2014-05-04 4:34 AM, Daniele M. wrote:
I have read this excellent article by David A. Wheeler:
http://www.dwheeler.com/essays/heartbleed.html
And since D language was not there, I mentioned it to him as a
possible
good candidate due to its static typing and related features.
However, now I am asking the community here: would a D
implementation
(with GC disabled) of OpenSSL have been free from
Heartbleed-type
vulnerabilities? Specifically
http://cwe.mitre.org/data/definitions/126.html and
http://cwe.mitre.org/data/definitions/20.html as David
mentions.
I find this perspective very interesting, please advise :)
I'm currently working on a TLS library using only D. I've
shared the ASN.1 parser here:
https://github.com/globecsys/asn1.d
The ASN.1 format allows me to compile the data structures to D
from the tls.asn1 in the repo I linked to. It uses the
equivalent of D template structures extensively with what's
called an Information Object Class.
Obviously, when it's done I need a DER serializer/deserializer
which I intend on editing MsgPackD, and then I can do a
handshake (read a ASN.1 certificate) and encrypt/decrypt
AES/RSA using the certificate information and this cryptography
library: https://github.com/apartridge/crypto .
I've never expected any help so I'm not sure what the licensing
will be. I'm currently working on the generation step for the
ASN.1 to D compiler, it's very fun to make a compiler in D.
This is a quite radical approach, I am very interested to see its
development! Have you thought about creating an SSL/TLS
implementations tester instead? With the compiled information I
see this goal quite well in range.
