What we describe on that link I gave you is a simple protocol using asynchronous key exchange with RSA (PKCS1 padding). We have not rewritten SSL, that would be pretty stupid since is SSL had so many problems throughout its history. We are using the BouncyCastle library for the main crypto functions: http://bouncycastle.org/
I'm not sure I follow this explanation too well, so I was hoping for additional information if possible,
Countermail says they have developed from scratch, sui generis
, a new secure network protocol (if I understand this correctly). that's a modification to or fork of (?) not OpenSSL
but rather of "SSL."
However, SSL as a protocol doesn't even exist any more; it was supplanted by TLS years ago, although TLS is obviously version-related to SSL and in many senses is "the same thing" at a general level. But we're not supposed to talk about "SSL" any more since it's deprecated, although we all do... and despite those three letters being embedded in names like OpenSSL, PolarSSL, etc. Nobody wants to change OpenSSL to OpenTLS, do they? Right.
But now they say they "have not rewritten SSL" - which is good, since it's dead and replaced by TLS - but are "using BouncyCastle library for the main crypto functions." They provide a link to BC's site, in case folks haven't heard of it before. Thanks, that's a big help - this crypto stuff is entirely unexplored terrain for me
Right, so now they've either forked BouncyCastle, or are using primitives (that's what most folks who work with such things usually call that class of algorithmic tools, rather than "crypto functions" which in mathematics would have a different connotation and really isn't ideal for this usage) from BouncyCastle in their new, not-SSL secure network protocol that is based itself on... no idea. I'm lost.
This is relevant to us, as in the near future we're likely to do a bit of careful pruning of the secure network framework within which cryptostorm network sessions take place. It's not a fork, nor even a tweak of the source code, but rather a shift in libraries used, and an explicit down-tuning of primitives we don't use so that even the potential for version downgrade attacks is excised from the codebase in our deployed binaries.
So we're really hoping to find best practices examples of this kind of work... and by everything that countermail says, they've done exactly that: they've written... something, some new protocol. Using BouncyCastle (?) as a primitives library. And whatever it is they've written, it can apparently talk comfortably with client-side cryptographic handlers, who one might assume would not know how to talk an entirely new secure network protocol without some protocol definition with which to work. Which maybe this new protocol somehow provides during session instantiation, via a novel form of pushed parameters, or..? I have no idea.
I'm lost, so hopefully they can help!