pqwy

This is more of an attempt to give little background on RNG problems in a security context, and a description of how MirageOS' crypto stack deals with RNG, with an emphasis on entropy harvesting.

No, or at least not yet. :)

You are probably thinking of these guys: http://www.mitls.org.

They have a killer TLS, but it drags the entire CLR in.

We are these guys: http://openmirage.org/blog/introducing-ocaml-tls.

Nope, not yet.

;_;

... back.

Because I'm looking at GBs of SYNs scrolling down the terminal.

Syn flood...

Update: DDoS, SYN flood. Stay tuned...

Why do you think this creates malleability?

PKCS1.5 stripping takes away the leading 0x00 0x01 0xff ... 0x00 -- if this prefix is not present, it fails.

The rest goes through the RSA tranform, and is parsed as PKCS1 DigestInfo, an ASN.1 structure. All ASN parsing checks for presence of trailing bytes, on top and in CONSTRUCTED nodes.

The presence of suffix-checking prevents malleability in my mind. Am I missing something?

Hah, and I wondered how come we suddenly started getting MITM connections from several places.

FWIW you can also do it with a single socat invocation, but I'll leave the exact command as an exercise for the reader.

Aaah, but you can try to do soooo much more!

You can try to confuse the ASN.1 parser, or even the protocol level parser.

You can try to defeat certificate validation logic.

You can try to get handshake state-machine do an illegal transition.

You can try to smash its memory and either read it or get your code into it.

You can try to defeat its RNG.

It doesn't let you do adaptive-plaintext attacks, but everything else is up for grabs. And you don't necessarily have to wait for it to politely send you the bitcoin key - it's somewhere in there, in memory!

Sounds like a nice exercise, I'll try it.

But since by and large the lines we have are expression and not statements (the core handler is purely functional, using a monad to thread errors through), this amounts to type errors immediately.

That is exactly the question we have. And yes, the primitives are in C largely due to timing concerns.

It concerns us too. Right now the entropy in Xen domains is weak, but we are working with the rest of the team to feed some actual environmental noise to keep Fortuna well-fed.

You can also run the library on Unix, of course, and there the RNG is periodically seeded from /dev/urandom.

Hey,

(Disclaimer: one of the authors)

We randomize the connection parameters on each connect to help us gauge the stack's behavior with various combinations (see https://github.com/mirleft/ocaml-tls/issues/159 ). Normally it uses first available from the list here: https://github.com/mirleft/ocaml-tls/blob/master/lib/config.....

(For some reason the RSA variant got on top; it should have been DHE_RSA, which does provide PFS.)

Side channel attacks were a very big concern, and I invite you to read the entire series of articles we plan on publishing in the next few days, where we try to lay down our strategy and explain what we know and what we don't. Or even skim through the handshake code and check some of the comments there.

We were already warned that CVE-2014-1266 CVE-2014-0224 are not memory safety issues. The article is badly worded there. What was meant is that they are, at least in our pretty firm opinion, issues with C (something we will elaborate in more detail in further articles, but in essence, you get regular control-flow in a functional language and you can encode state machines in a far more explicit manner). Working to update the post and clarify this.

As for the issue #6, yes, its closing was not documented too well. This does not mean we didn't expend significant effort to actually address the points there :) .

Thank you for the input and please have patience with us. We still have (at least) four more articles to publish!