First off, we'd like to thank the small group of beta testers who have been helping us to prepare the new darknet & related client code for full-scale production release. They're a patient group, as we've been somewhat brutal in pushing for an implementation of cryptographic cipher suites that hasn't been done with VPN-based technology before in a production/consumer network. That patience has allowed us to set a high goal and adhere to it - kudos to all!
Now, on to the production updates:
1. We've successfully deployed exactly the configuration of ephemeral Diffie Hellman key exchange and symmetric ciphers that we'd targeted in our initial network build-out last month. That's good. There's been some wrestling with the mechanics of elliptical curves - infamously a bit touchy to get going - but so far mostly things have adhered to TLS 1.2 spec. We're not seeding the curves with our own custom parameters, yet... that's now a 1.1. function as it's going to take additional consultation with academic cryptographic researchers to ensure our seeding methodology is rock-solid.
2. We've reached agreement with the first round of independent network token distributors, who are themselves polishing up the interfaces to their token-purchase engines. We're really pleased with the process flow that's coming together in this NT framework - it should be smooth and efficient for network subscribers to buy tokens, receive them from the distributors, and hand them to their network access widget locally in order to join the darknet.
3. The network tokens themselves... we've polished the mechanics of their creation ("minting"), storage, timed expiry, and authentication to something quite elegant (if we do say so ourselves). Post-launch, we're hoping to write up more details about how the system itself operates, top to bottom. Further, in a 2.0 release we're moving steadily towards a public blockchain-based auth procedure that is completely transparent and independently verifiable.
4. Hardening our initial exit nodes has been a lengthy, somewhat exhausting process - just being honest about that. What we might have considered acceptable "endpoint security" (because, in this topological model, exit nodes are a form of endpoint) pre-Snowden we've simply concluded isn't enough to offer serious resistance to TAO-level NSA threat vectors... and we've thrown out the rulebook, starting at the kernel level and reevaluating every decision we make. It's not very glamorous and it won't be in any banner advertisements, but this backend hardening has eaten the most time in the past few weeks. Don't ask our network sysadmins about the security considerations of virtualized network interface bridging... they might bite your nose off, at this point. Bit of a sore subject - but we hope we'll all get over it and regain our manners in due course!
5. Network access widget (i.e. "VPN client") functionality is almost there... but not quite polished to production class yet. Our own Pattern_Jugged has become obsessed with eliminating steps in the UI/UX process flow - to the point where we're debating individual widget buttons and which words can be shaved from dialogue screens to keep them as low-friction as possible for subscribers to use. If we do this right - and if PJ's obsession with this particular issue bears tangible fruit - the 1.0 widget will all but disappear from awareness as it does its job: less really is more, here.
That's the main basket of production updates. There's a whole pile of additional little tidbits that have been accomplished, but really are not terribly interesting to most folks.
One thing we're close to formally announcing is a decision to formally opensource the detailed settings of the openvpn config files - both client- and sever-side. This has never been done before, but we're not coming up with any compelling reasons not
to do it, and we think it can help foster independent audit & review of our choices - which improves security for subscribers, ceteris paribus
If our exit nodes pass their "burn-in" stress test of security hardening, we're ready to stripe on production code and formally open the beta of the network to existing Cryptocloud customers who have already requested NTs be issued to them via the request form on our main website
. That will come in x days, with x being an integer expressed in one digit in base-10 nomenclature. Barring unexpected snags that require additional node hardening, of course.
Given that the beta flow works smoothly, we might - might
authorise the sale of the first "outside" NTs to new subscribers, via independent distributors, before this weekend. If you've already submitted a request to be notified of that via the form noted above, you'll be the first to know of available NTs. Wider availability will be announced from there.
Finally, we'd like to formally apologize to anyone who has emailed us - via our main contact address
or to individual team members - during the past couple of weeks. The decision has been made to defer efforts to respond to these queries until the beta is under-way, so that all team members can contribute their full attention to the network design and rollout. It's an honour to have so many folks emailing us with smart, insightful, often very informative questions and feedback/suggestions - we read them all as they come in, and discuss in our daily "scrum" development sessions. We'd love to be replying to each one immediately, but it's just too much volume for our staff to do properly right now. Instead, we're holding them and will be replying with more substantive responses post-beta... which, per above, should be shortly.
The word "deathmarch" gets used in tech projects sometimes - mostly on the coding side of things - when it's time to lock down specifications and produce code that compiles and runs clean. That makes it sound tragic and unpleasant, but in truth there's an intensity and integrity of focus that comes in "deathmarch mode." We've been in that mode, as a team, for almost exactly one month now. It's been exhilarating, and exhausting, and amazing. We're really proud of what we've created - as a direct result of the encouragement, advice, suggestions, critiques, and feedback we've been receiving from our supporters and the larger community for many years. It's a wild ride.
And with that, we'll finish up our (hopefully) last pre-production update in this thread with a quote. This is from Wired
magazine co-founder Loius Rosetto
, recalling the heady early days of the magazine's launch... into a world that assumed tech was boring, dry, corporate, and largely invisible:
"There's something about investing your humanity, your eccentricity, your exuberance in the things you do. Why do people watch tightrope walkers? Not to see them get to the other side. It's because they might fall. Not everything you do is going to be successful, but tht's part of the allure. It's also what makes the work valuable: that you're really present and invested in what you're doing."
It might seem odd to equate our work in crafting the cryptostorm secure network with something as "foo foo" as launching a glossy consumer magazine - but it's not. As anyone who has worked hands-on with real tech for any length of time can confirm, behind the scenes the construction of new tech systems is as much art as science. We invest our experience, our accrued wisdom, our wins and losses and successes and tragic failures, our hopes and fears and dreams, our assumptions and knee-jerk gut feelings, our hearts and our souls... we invest all this in a tech project that really means something.
It might seem (to pick an example) like choosing cipher suites is just a dry, brittle, purely objective task - but it's not. Not when it's done right, anyhow. If it's done right, it involves the investment of a part of ourselves in those choices... there's all the "hard" facts about what works and doesn't, of course. But, there's also all the rest - the real meat of things, the subjective "this is what sings" side of the equation. And it matters - yes, even in "heavy crypto" projects such as cryptostorn. Perhaps, in the end, it matters there most of all.
It's easy - and lazy - to just let the "system" choose its default settings, and assume "someone" must have thought out the details. It's also very common in the "VPN industry" (check the ca.cert files pushed by most VPN servers: they're the totally insecure, default ones that ship with the OpenVPN tarball itself). "Building" a system like that is pathetic. Not only is it brittle and likely unreliable, it's also guaranteed to be far less secure - because no one person (or team) has really thought out how the pieces fit together
. And the definition of a "system" is the fit-together part, not merely the pieces thereof.
To create something genuinely new, to breathe life into a system - whether it's built of electrons and code, or it's built of wood and nails, or paint and a canvas - is beautiful. It's also risky - it might not work, and it might never come to completion. To start with a blank piece of paper, as any writer can confirm, is deeply intimidating... and also profoundly empowering.
This is the cryptostorm darknet. We've poured ourselves, as individuals and as a team, into it. It reflects our best thinking, our decades of front-line experience, our scars and our secret dreams of doing the impossible. It's not perfect, and it will be improved over time - it will also be subject to wide public review and critique. But we know, in our hearts, that at a deep structural level we've created something good: something that will help set the stage for what comes next.
With genuine respect,