Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞
Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ

cryptostorm: pre-launch discussions | CLOSED

Looking for a bit more than customer support, and want to learn more about what cryptostorm is , what we've been announcing lately, and how the cryptostorm network makes the magic? This is a great place to start, so make yourself at home!
User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

cryptostorm: pre-launch discussions | CLOSED

Postby cryptostorm_team » Thu Aug 22, 2013 6:31 pm

When choosing both your networkID (i.e. “username”) & password for cryptostorm, you'll notice there's some constraints on what you are able to choose. Some of that is pretty obvious - choosing three-character passwords is perhaps not so much a good idea - but in other matters it's a bit counterintuitive.

For example, we're not accepting inputs of "special characters" (let alone full-bore Unicode craziness) - which would seem to go against choosing "strong" passwords and networkID settings. So, what gives?

As we take your initial subscription data and it becomes the "key" with which you connect to the darknet in the future - irrespective of chosen exit node - that key ends up being an essential component of system-level handshakes across the network. A classic "bug" in VPN services run by inexperienced teams is to allow complex parameters into the front of the system, and then have some other element of the architecture turn its (virtual) nose up at a particular flavour of character - resulting in failed authentications.

To avoid that - not just now but in the future, as the network upgrades and evolves - we take a "least common denominator" approach to these parameters. Keep it simple: upper & lowecase (English) letters & alphanumerics (including standard punctuation). If you try to submit stuff that's outside that constrained little world, our forms will politely request you simplify. Please don't take it personally - it's all in the name of good, reliable security.

    some of this also flows from our decision to build our fundamental architecture on the basis of interlinked, open toolsets - versus canned stuff from a particular vendor; with an broad weave of various tools forming the core of our network, it's no surprise that some opensource project teams might choose "tighter" hygiene procedures for certain variables... which, in turn, would become unhappy if handed a value that has non-defined characters included in it

We do understand that, for some folks, this is a bit of a hassle. A favourite username can sort of become part of us, eh? However, these networkIDs aren't ever visible publicly; they're used only for your authentication into the darknet. For example, you may choose whatever username you prefer, if you decide to register here in the forum.

Finally, making this choice in favour of "tight" parameter hygiene means that we keep our options open, in the future, when it comes to adding in newly-birthed opensource components to the network itself. Otherwise, we might find something quite useful... but see that it won't like our broadly-defined variable settings and thus, in practice, be removed from the options we're able to consider as network architects (or, we'd implement some sort of dynamic parameter scrubbing intra-system... which gets ugly, and unreliable, and insecure - fast).

So, it's not perhaps as arbitrary as it might seem on the surface. Indeed, it's part of an overall commitment to the highest possible OpSec procedures for a secure network environment.

    ~ cyptostorm_team
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: [email protected]
live chat support: #cryptostorm

User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

cryptostorm: pre-launch discussions | CLOSED

Postby cryptostorm_team » Thu Aug 22, 2013 7:48 pm

Ok, for everyone who has submitted a request for a network invite (via the invite form, naturally) - both prior members of Cryptocloud & new folks alike - this thread is where we'll be updating on the status of the new cryptostorm network.

Per notification via twitter just a few minutes ago, we've got our first production-class machine up and running.

As with all lour production machines in the darknet, this one will be undergoing some internal stress-testing to ensure it's ready for use by our subscribers. This is normally not a lengthy process - unless something looks wonky in test output - but it's also not something on a fixed timeline. So we're leaving this as a "date of public availability to be announced shortly" entry in the ETA column.

...

We've also made a second decision regarding the public availability of the darknet:

As some of you know, Cryptocloud was the first customer-focused "VPN" company to deploy OpenVPN in our network, back in 2008. Since then, we've wrapped the core OpenVPN C-coded engine inside a Java user interface (UI) shell, to make the installation & use of the client connection software more convenient for our customers. That has been widely copied by others in the "VPN industry," and is not more or less standard practice.

Fuck standard practice.

We've been watching this architectural decision we made back in 2008 - take the core OpenVPN engine, wrap it in something pretty, compile (to bytecode for Java, or to full-on binaries for other toolkits), and have customers install on their computer - evolve into today's bloatware masquerade of "VPN client" atrocities. Mutate - that's a better word than evolve. We've seen client code out there that's got (putative) "speed monitors," (which, when tested, seem to generate random data - but lots of pretty graphs :problem: ), (putative) "leak blocking" hypeware (that doesn't do anything useful whatsoever - when tested with wireshark), oodles of marketo-branding blather, logos, splash screens, popups (seriously... popups - wtf?). You name it.

At the same time, we've been testing those clients - and our own client - for leakiness. Alot. And we don't like what we've seen. OpenVPN itself "leaks" alot - it wasn't designed not to leak, basically. Worse, many of the client-side "wrappers" painted over top of the core OpenVPN engine are utter disasters, security-wise. They leak. They crash unexpectedly. They "fail open" and otherwise break all standards of good security tech. Ugh.

Our client app is no exception. Sure, it's not terrible - we designed it, and we did our best. But from today's vantage, it's not up to speed. Some of the ciphers in it aren't appropriate for use today (crypto geeks: take a peek at an old connection logfile - you'll see). The handshake itself assumes SSL isn't broken... and it is. Plus, um, Java (no longer subject to 0days, as the quip goes, but rather "everydays"). And so on.

Time to move forward.

We've made the decision to ditch entirely the old client app, the essentials of which we've been improving and deploying for more than five years. It's time. We can keep patching the drippy bits... but that's no longer a constructive approach to the larger issue.

Fortunately, this isn't a new decision. In fact, our tech team has been working on a next-iteration client app since the dark days of winter. Not a simple process - we've found our way through a whole range of questions and decisions and new methodologies, along the way. Yes, it's still based on OpenVPN - that engine is solid, tested, and reliable. But it dynamically interconnects to the engine, rather than simply painting a UI over top of it. Authentication is an integrated process - not just handing parameters around and hoping it all turns out ok. And routing table setup, management, and tear-down is explicit, intentional, and well-tested.

Oh, also it's architected ground-up to be cross-platform. No more fiddling with various "GUIs" for different OS flavours - it'll all be different compiles of the same core framework & codebase, for our client-side executables. That goes for Windows, Linux, Mac... all the desktop stuff. The smartphone side of things? Oooo, well we've got something up our sleeve on that side that's getting it's own formal announcement straightaway.

Did we mention that our client app is 100% opensource, & that we're publishing the code from day one for public review? Yes, there's that. As it should be.

Our new client app has been in early alpha testing for a few weeks already. It's done great, so far - but there's still some polishing. It's not ready to push into a public beta yet... but it's close. So our ETA on that is also listing "date of public availability to be announced shortly."

Which ties up nicely with our new exit node configuration and testing, in fact. Woohoo!

- - -

Folks who have already requested an invite code will be notified when the public availability date is officially fixed in place - and of course when that day arrives, they'll receive their darknet login credentials. So of course the question is: when?? We're going to say - without, we hope, cursing the process in doing so - that the release date won't be this week (sorry), but it's also not going to be n months from now, with n being a number larger than 1. <tossing salt over collective shoulder>

Prior to that date, some folks will hear from our tech team as to whether they'd like to do some early beta shakedowns with the new client.

That's what we've got for a production/public availability update currently. We'll continue posting news in this thread as things count down. Those not wanting to wade through the tech blather here can always follow the cryptostorm darknet twitter feed - it all gets announced there, too, and in 140 characters or less! :clap:

An exciting time, indeed - the birth of a new industry.

    ~ cryptostorm_team
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: [email protected]
live chat support: #cryptostorm


spotshot
Posts: 131
Joined: Sun Feb 10, 2013 11:23 pm

Re: Production stats: updates on "go live" of cryptostorm

Postby spotshot » Tue Aug 27, 2013 7:17 am

how is production status, is everything looking good?

User avatar

Pattern_Juggled
Posts: 1493
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Re: Production stats: updates on "go live" of cryptostorm

Postby Pattern_Juggled » Tue Aug 27, 2013 8:38 pm

spotshot wrote:how is production status, is everything looking good?


<popping out of the development scrum for a few minutes...>

The production work, if I may summarize, seems to be moving along nicely. There's been some wrestling with the elliptic curve stuff to implement a flavour of TLS that's not useless... and that's a more involved process than it would first appear. Many kernel recompiles later, we're getting the hang of it - apparently. :eh:

I've been helping out in the implementation mechanics of the new (as in, nobody's-ever-done-it-before-new) tokenized "auth" system - the interface between the world of payments and the world of the darknet itself - as it does draw on some of my own academic background. Personally, I'm pretty excited about this side of things; it pushes all my buttons. But I'm not (yet) authorised to make much in the way of a public statement on what it's all about. Yet.

But it's, if I may say so, a qualitatively better way of handling network auth, period - in terms of customer privacy and network resilience. I remember first wrestling with these sorts of issues back in 2007... and alot's changed since then. Like - alot. And yet, basically every "VPN company" out there does the same thing as back in the day. Huh?

It's likely the rollout will be in staged tranches: first, current Cryptocloud folks will be handed auth tokens to hop on, along with some outside beta testers. Once the payment stuff (can't say more) is fully in place, new folks will have a path to darknet access - and then the only bottleneck is scaling network resources, which I think we're fairly good at.

Right now, the first wave of outside invites is (so I hear) all but closed out. That means there'll be some sort of temporal queuing mechanism for folks coming to request invites moving forward - nothing complex, but it'll take a bit of jiggering to ensure it runs smooth.

Anyhow, that's the sort of stuff that's being ironed out. The core darknet connectivity, client design, and coding stuff was done a long while back - already finished up, just polishing up the shiny bits now :thumbup:

Cheers!
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

marzametal
Posts: 487
Joined: Mon Aug 05, 2013 11:39 am

Re: Production stats: updates on "go live" of cryptostorm

Postby marzametal » Wed Aug 28, 2013 6:12 am

Cheers for the update :)


Rider
Posts: 97
Joined: Tue Jan 01, 2013 11:21 pm
Contact:

Re: Production stats: updates on "go live" of cryptostorm

Postby Rider » Fri Aug 30, 2013 8:32 am

How are things coming along guys?


Guest

Re: Production stats: updates on "go live" of cryptostorm

Postby Guest » Thu Sep 05, 2013 9:31 am

hey guys, it's been about a week, how is status of new work?

User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

Production update: 5 September

Postby cryptostorm_team » Thu Sep 05, 2013 5:51 pm

Guest wrote:hey guys, it's been about a week, how is status of new work?


Ok, here's the production update:

    First, the heavy lifting in structuring and implementing the token-based auth system is complete. Details on what it's all about can be found here if you're curious about the background. In practical terms, login to the network will be easier - only a token required - and the token purchase process is shaping up to be elegantly smooth as well.

    Second, we're still in process of fine-tuning the kernel build on our production exit nodes. We're very, very picky about kernel integrity. Plus, we're building in Perfect Forward Secrecy (PFS) as an SSL/TLS option right from the start - rather than trying to stripe it in later (which ends up being very difficult). Once we green-light the production kernel build, it's a very short hop to full production for the exit nodes themselves.

    Third, the rest of the infrastructure for customer management is already finished... mostly because we're stripping out big chunks of the entire idea of a "customer database" for the darknet itself. See tokens link above, for the conceptual framework behind this move towards increased customer security. All of the "command & control" architecture - which is minimal but certainly nonzero - is up and running in Iceland.

    Fourth, the network connection widget (i.e. "client application") is still doing its paces in alpha testing. We've been engaged in some heavy surgery wrt auth mechanisms, as part of the token-ization framework... most of which involves removing non-essential components from the widget itself. You'll see when you review the published source code: it's a "less is more" approach to genuine security.

We've discussed pre-issuing NTs to current Cryptocloud customers so they have them in-hand, but the decision currently is to hold off until the new widget is ready for distribution as well - thus, when you receive an email with your access NT you'll also get the link to the new widget (along with SRC, if you're curious) so you can be up and running on the darknet immediately.

Our infrastructure folks are in discussions on leasing dedicated machines in some additional, high-security jurisdictions... not allowed to disclose those yet, but when they come out we think folks will be pleased.

Our task management system shows key dependencies being checked off one after another... there's still a few essential bottlenecks to complete before "go live" date hits, but that handful is small and getting smaller by day. ETA is... as soon as we can say with confidence that's it's fully ready for member usage, no hesitation and no unresolved issues.

    ~ cryptostorm_team
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: [email protected]
live chat support: #cryptostorm

User avatar

Pattern_Juggled
Posts: 1493
Joined: Sun Dec 16, 2012 6:34 am
Contact:

topic split

Postby Pattern_Juggled » Fri Sep 06, 2013 2:52 pm

Note: I've taken the liberty of splitting off the discussion on ECC & related topics into its own thread to encourage ongoing development of both those subjects and this more general thread discussing implementation-specific issues. No changes to any actual content of any posts have been made during this organizational step.

I've also moved over an excellent question regarding tokens to the main tokens thread as it does tie directly into those onging discussions - which I hope is acceptable to the OP posing the query itself; if not, OP, let me know & I'll move that post back into this thread... although likely my reply will remain in the tokens thread so it's visible to more folks seeking information on that particular topic. Thanks for your patience with my efforts to keep some structure here, without unduly/needlessly stepping on the decisions folks make regarding where they'd like to contribute.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

Pattern_Juggled
Posts: 1493
Joined: Sun Dec 16, 2012 6:34 am
Contact:

thread split

Postby Pattern_Juggled » Tue Sep 17, 2013 4:40 pm

I've just split off several posts on the topic of "FBI OpenBSD Backdoors and RSA Cipher Vulnerability," to their own thread, to keep the discussion friendly for new folks arriving mid-stream.
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f


Guest

Re: Production stats: updates on "go live" of cryptostorm

Postby Guest » Tue Sep 17, 2013 5:55 pm

any news worthy updates?

User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

17 Sept 2013 production update

Postby cryptostorm_team » Tue Sep 17, 2013 7:32 pm

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,

    ~ cryptostorm_team
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: [email protected]
live chat support: #cryptostorm


Guest

Re: Production stats: updates on "go live" of cryptostorm

Postby Guest » Wed Sep 18, 2013 5:33 am

Damn.. You sure know how to put a closer on your statement. Bravo.

Can't wait!

This is the dawn of a new era. Strap yourselves in. It'll be a fun ride :)

Its like the cryptowars of the 90s all over again.

User avatar

marzametal
Posts: 487
Joined: Mon Aug 05, 2013 11:39 am

Re: Production stats: updates on "go live" of cryptostorm

Postby marzametal » Wed Sep 18, 2013 6:44 am

Cheers for the update! I feel useless that I cannot help... haha


spotshot
Posts: 131
Joined: Sun Feb 10, 2013 11:23 pm

Re: Production stats: updates on "go live" of cryptostorm

Postby spotshot » Tue Sep 24, 2013 10:33 pm

are things getting closer?

User avatar

Jarmer
Posts: 15
Joined: Sat Aug 17, 2013 9:10 pm

Re: Production stats: updates on "go live" of cryptostorm

Postby Jarmer » Tue Oct 01, 2013 10:59 pm

Wow, what an amazing post, that most recent team-cryptostorm post, was. I am VERY excited to begin using this, and start supporting your efforts at the same time. I'm more than willing to wait until you all are ready at the same time.

Thank you very much for the status updates, and this forum in general, loving it!

User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

First tranche tokens for 0.9 late-beta network

Postby cryptostorm_team » Wed Oct 02, 2013 12:44 am

Thanks for the kind words, Jarmer.

The entire team has been sort of absent from the forum (versus usual activity), and our usual rotation of folks to follow the twitter feed is pretty much in total chaos... as we get the final touches on the network rollout. We'll be back to normal operations shortly.

Ok, that said, the first round of Network Tokens (NTs) are just about ready to distribute. They are reserved for current cryptocloud.com customers. If you're a current customer of the old network - i.e. cryptocloud.com - then you need to reach out to us to let us know your contact info. Again, we've not done a "migration" of the cryptocloud.com customer database. Cryptostorm, by design, has no "customer database" to migrate into, and beside doing things that way would break all sorts of core OpSec procedures.

Please, the best way to contact is via the snazzy form available on our website; it's specifically designed to make this process super-easy, with minimal fuss. We queue that manually into a simple email tool & from there we'll send your NT to you. If you want to have it done via encrypted (i.e. PGP) email, that's no problem - just point us at your public key, or drop us an email at info<at>cryptostorm.is with your key creds in it & we'll send yours that way. NTs are secret and really should be treated as sensitive, so doing things encrypted is best. They're also temporary, by design, and don't "unlock" anything except network access (more on that later, in a formal cryptographic systems whitepaper on the new network design).

Basically we think it's ok to email them, even plaintext, for most folks. If your threat vectors are nonstandard, then let us know so we can PGP them to you. Note that, in the future, NT distribution will be more automated and hard-secured by our resellers. This is a temporary process, now, to get current customers migrated. Yes, it's not perfect - we know that.

Once this tranche of folks is connecting smoothly, we'll then begin offering tokens to folks who aren't currently customers. Again, if you've filled out the request form, we'll be emailing you with a pointer to available token resellers. If you haven't filled out the form, you can only access tokens after those folks have gone through - if there's capacity left. We're calling this the 0.9 version of the network - still a beta, albeit late-stage and already cryptographically and server-hardened - and there's limited capacity in the network. Once we've sold enough tokens to meet that capacity, no more will be sold until we've added more machines (which, to be fair, is a smooth process as our entire infrastructure is Xenified from the metal up).

It's also fine to DM us here if you'd like to receive your token that way, as a current cryptocloud.com customer. Pretty secure, too.

Finally, when you get your NT via email, there will be a link to the new client application (we call it a "network access widget"). That link will point to the self-installer, posted here in the forum, as well as a really minimalist "opensourcing" of the underlying Perl code: we'll be pasting the 0.9 codebase into a {code}code block{/code} here on the forum. :-P Not very fancy, but it's a start. Yes, we're likely to push it to some flavour of git down the line, so we can bring in community feedback and edits more smoothly. But we want the code to be visible from Day One, for transparency's sake. Besides, we're not talking millions of lines of C code here, or anything. It's Perl, eh? :-)

If you know other cryptocloud.com customers, please do point them at this post so we can get folks coming over smoothly. Our current infrastructure has capacity to, in theory, handle every current customer of cryptocloud.com with no snags - so there's no downside to tell your buddy that she's welcome here, too! :thumbup:

Ok, we'll post here once the emails start queuing out - that just depends on the mechanics of getting NTs loaded into the mail engine, etc.

Thanks again - off we go... "Buy the ticket, take the ride." ~ H.S.T. (R.I.P.)

    ~ cryptostorm_team
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: [email protected]
live chat support: #cryptostorm


Rider
Posts: 97
Joined: Tue Jan 01, 2013 11:21 pm
Contact:

Re: Production stats: updates on "go live" of cryptostorm

Postby Rider » Wed Oct 02, 2013 6:16 am

Excellent!! I think you should post another Sticky once the E-Mails are sent out :)


Guest

Re: Production stats: updates on "go live" of cryptostorm

Postby Guest » Tue Oct 08, 2013 8:24 am

with these network tokens and cryptostorm VPN. are we protected from these quantum cookies? the govts way of man in the middle? I hope you've noticed the article by now

User avatar

Pattern_Juggled
Posts: 1493
Joined: Sun Dec 16, 2012 6:34 am
Contact:

Quantum tokens & MiTM

Postby Pattern_Juggled » Wed Oct 09, 2013 5:05 pm

Guest wrote:with these network tokens and cryptostorm VPN. are we protected from these quantum cookies? the govts way of man in the middle? I hope you've noticed the article by now


Given the caveat that we know little about the actual technical underpinnings of the "quantum cookies" referenced in Snowden's latest batch of disclosures and thus there's a certain amount of logical inference we're all doing as to how they seem to be structured technically, they are not an overt threat to subscribers using the cryptostorm network to subvert NSA-sourced surveillance.

The attacks on Tor rely on the fact that Tor itself operates (in default mode, although it can be modified almost without limit) in conjunction with individual applications. In many cases, as for example with the Tor Browser Bundle, it's acting to "torify" only the web browsing sessions from within that browser framework. As such, clever cookie techniques that break out of that metaphorical sandbox can unmask users. That's also why Flash and other such plug-ins are a big risk in this sort of setup.

A secure networking tool that eschews application-layer interactions and instead steps down to the network stack and/or OS level can obviate these sorts of concerns, at a structural level. (note: javascript-based browser attacks of the sort used by torsploit can break this security model, as they are in theory able to scrape the physical IP from the physical NIC of the machine in question - essentially, having rooted the OS itself)

Thus, clever cookie attacks aren't really well-suited to attacking a fully "wrapped" network security approach such as that deployed by cryptostorm. There are other attack vectors that do exist to enable this kind of unmasking - so I'm not saying this model is "immune from attack," or any such claptrap. Rather, it's just that cookie-based attacks aren't really dispositive.

(if someone comes on and off the secure network routinely, using the same computer and same web browser across time, then cookie-based attacks are relevant - a line of inquiry surprisingly rare in terms of how often folks consider its implications)

Breaking out of the browser, when using cryptostorm, is sort of a waste of time (ceteris paribus); all an attacker gets is access to the virtual NIC-mediated network environment, which doesn't provide much in the way of useful intel. That's one of the benefits of encapsulating all network traffic within a secure channel - the risk of "leakage" (as is such a big concern a selectively-encapsulated configuration) is qualitatively diminished. Leaks can occur of course, but they are overt failures of systems engineering - rather than exploitation of structural realities of the properly-deployed tech itself.

This is, however, an entirely different question than that of MiTM attacks, more generally. Quantum cookies aren't really an MiTM attack (although it seems, from hints in the document dump, they might be "injected" via MiTM-style) techniques, originally. True MiTM attack vectors, whether passive or active, are a serious concern for any network security methodology.

Cryptostorm has done some things to dramatically drop the practical risk of successful MiTM attacks via in-the-wild techniques known to exist today - from independent attacker models up through NSA-level blanket MiTM subversion of encrypted network techniques globally. We can't say it's a perfect form of protection against MiTM - an "oracular" MiTM attacker can, at a theoretical level, break any and all wire-based security (absent assumption of perfectly secure out-of-band key exchange channels being available routinely... which simply isn't how things work nowadays). I don't know of any theoretical - let alone practical - techniques to protect against that fundamental class of MiTM threats... nor do I know of examples where that's being done routinely, or even selectively. It is, however, an area of study receiving far from sufficient attention since we now know there's an attacker with enough resources - and insulation from any law-based limitations on its actions - to mount such attacks if they so choose.

I will say this, after months of looking into this as part of my work for the cryptostorm launch team: every "VPN company" I've looked at thus far is profoundly vulnerable to known-viable MiTM attack vectors documented in the wild already today. Every one. Maybe someone out there is doing a good job of protecting against them; I've failed to find and document them, during this research. It's pretty frightening, to be honest.

Details of the cryptostorm approach to MiTM protection are being published as part of the network launch; I'm helping with some of that write-up, along with the good folks over at Baneki Privacy Labs who have themselves done much of the heavy lifting in this core crypto engineering work for the launch. There's nothing we've done that isn't being published and presented for full public review and critique - no lame attempts at "security through obfuscation" (although Jaron Lanier does point out that, in biology, we call that kind of thing "biodiversity" and consider it a feature, not a bug). We think we've made some good implementation choices, and we're keen to see if other cryptographic experts can help us improve further from there.

I don't have an ETA for those publications; my hunch is that much of it will come up in forum threads here, somewhat informally, very shortly - with "formal" publication down the line once the team has time to write things up properly. But that's not an official position on behalf of the entire team, at least not yet anyway.

Regards,

    ~ pj
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

production update: 9 October

Postby cryptostorm_team » Wed Oct 09, 2013 5:16 pm

Rider wrote:Excellent!! I think you should post another Sticky once the E-Mails are sent out :)


Excellent suggestion, and indeed it shall be done.

We're still "almost ready" to send out those first NTs. They're minted and ready to go, but there's been some debate amoungst the team on how to distribute with sufficient security. That is (mostly) settled and the first wave of notifications will be headed out shortly.

We'll also post notice here when that takes place.

More generally, test network connects have been successful and we've completed the aforementioned work in stabilising all the network elements needed to deploy PFS properly and reliably. This was nontrivial; more on that understatement when we publish our notes on our cryptographic infrastructure - due in the very near future.

Final tweaks of the client application - the "widget" - version 0.9 are currently being done. Mostly this is tuning of graphical elements and some thorny UI decisions. We already have a list of incremental tweaks we're planning for the "official" 1.0 rollout of the widget, but the 0.9 version is certainly solid and we're happy with its underlying technical performance. It's not as pretty as we want to see - not as minimalist, basically - but we're getting there.

Sales by resellers of Network Tokens should be green-lighted shortly, a matter of days. Again, tokens already are minted & simply awaiting distribution to the channels.

Which is to say, in a sense, that we're in the midst of a "soft launch" already. That's nontraditional - we're not going to have some big launch party with distaff surprises launching themselves from giant cakes, or any of that. Sorry. Mostly our focus is on ensuring we're closely monitoring network rollout to ensure there's no hiccups in the security architecture itself - the rest of the fanfare about publicity and whatnot is of minor significance, in comparison.

Given the interest we've received already from folks interested in joining the network, we're already queued to add server capacity quickly. That's been part of the challenge of launch - we chose to ensure we could grow, and grow fast, as needed. So be it.

More news shortly. Also, if you know anyone who is an absolute master at customer support and customer care - world class attention to detail and commitment to professionalism - we're soon going to have such a position to fill. More details posted shortly, but we prefer to let "insders" know first, as that's always been how our team grows most organically.

    ~ cryptostorm_team
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: [email protected]
live chat support: #cryptostorm

User avatar

Pattern_Juggled
Posts: 1493
Joined: Sun Dec 16, 2012 6:34 am
Contact:

0.9 UI

Postby Pattern_Juggled » Thu Oct 10, 2013 4:31 pm

We like? Yes, we like.


“Less is more; God is in the details.”

(not so sure about the “God” bit, but the point stands...)
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
[email protected]ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f


jdurne
Posts: 7
Joined: Sat Feb 02, 2013 12:27 pm

Re: 0.9 UI

Postby jdurne » Fri Oct 11, 2013 1:13 am

Pattern_Juggled wrote:We like? Yes, we like.

mainscreen_widget0-9rev.png

“Less is more; God is in the details.”

(not so sure about the “God” bit, but the point stands...)


Me like alot. :)

User avatar

Topic Author
cryptostorm_team
ForumHelper
Posts: 159
Joined: Sat Mar 02, 2013 12:12 am

final update

Postby cryptostorm_team » Fri Oct 18, 2013 8:17 am

We're officially in production, as of this morning.

Look to threads elsewhere in this "launch" subforum for specific details, procedures, updates, and whatnot.

Cheers,

    ~ cryptostorm_team
cryptostorm_team - a shared, team-wide forum account (not a person)
PLEASE DON'T SEND PRIVATE MESSAGES to this account, as we can't guarantee quick replies!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: [email protected]
live chat support: #cryptostorm


Return to “cryptostorm in-depth: announcements, how it works, what it is”

Who is online

Users browsing this forum: No registered users and 2 guests

Login