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.
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?
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!
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.
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.
(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!