Page 1 of 1

cryptostorm: All Tomorrow's Tokens... or, auth done right

Posted: Tue Aug 27, 2013 2:40 pm
by cryptostorm_team
{direct link:}

Authentication, VPN "Privacy" Networks, & Tokens - rethinking Darknet Access Control
  • Why do we do things this way, and not that way... indeed, why do we do some things at all?
...sometimes, the right question to ask isn't whether it's possible to do a particular task "better" or "faster" or cheaper" but, instead, whether the task is necessary in the first place. Sometimes, it turns out that we're scrambling to improve a process that isn't adding any value at all - or that actually hinders what we really want to be doing.

One of the luxuries of building a next-generation privacy network from a blank slate is the opportunity to radically reevaluate previous assumptions about how to do things... and about what needs to be done, or not done, at all. This isn't the kind of luxury available via incremental changes; it requires that blank canvas on which to create from scratch. It's the core reason why the cryptostorm team has chosen to walk away from the old Cryptocloud VPN network and create something entirely new.

When we made this decision, we had a list of things we knew we wanted to improve - and an equally large list of things we knew had to be changed to protect against new-generation threats (BEAST/CRIME SSL attacks, the NSA's PRISM program, the XKeyscore interception toolkit, etc.). We also had some deeper intuition that one area, in particular, was ripe for radical overhaul: network authentication.

Sounds boring, doesn't it? Actually, it's not - and here's why...

"Can I Use the Network... Please?"

Secure networks, private networks, "darknets," heck even the oldster term WANs all refer to networks-within-networks. Once we have access to the internet itself, we can send and receive packets with others who are also using the same TCP/IP protocols. But if we want extra security, we're going to be looking for a network-within-the-network - call it what you will, they're all essentially the same structural creations. Partition off some space (virtual, not physical), add on some cryptographic goodies, design in clever stuff relating to routing data and/or anti-traffic-analysis methodologies... and you've got yourself your standard-issue darknet of whatever particular flavour.

Right off the bat, there's a core decision to make: does the darknet allow anyone to use it, or is it limited access? Limiting access might be because we don't want some class of users participating - but, far more often it's a question of network resources. Managing network resources takes us in one of two possible, diametrically opposed directions...

On the one hand, we might have an "open access darknet" such as the Tor Project. You don't need a secret handshake to use it - anyone can join. You don't have to buy credits, or a subscription, or anything whatsoever to route stuff through Tor. As such, there's fundamentally no question of network authentication - you show up, you ask to route data through Tor, and Tor routes your data.

On the other hand, there's access-limited darknets - the classic examples in today's market are "VPN companies." They run a series of exit nodes and encrypt traffic between client computers and those exit nodes (alot like Tor, in that regard), except you have to have a secret handshake to make use of the networks. Some are "free," which is to say advertising supported - but even those, you need to sign up, register, log in, and so on. The rest are paid: you pay money for a subscription, and that subscription buys you access to the network. No subscription, no access. Pretty simple stuff.

Now, obviously the big issue here is network provisioning: the open access Tor network is always struggling with infrastructure: since they rely on donated network resources, there's a constant struggle to keep enough donated goodies available to serve everyone who wants to use the Tor network. Worse, the more capacity they manage to finagle out of donors, the more folks show up to make use of the network - the better the network runs, the more people use it and the slower it will inevitably become! Tor's success ends up making the job of their team harder, because they need more donations to keep things running smoothly. In practical terms, Tor is - and always will be - resource constrained. That means, in simple terms, it's slow. Open access all but guarantees that'll be the case.

In contrast limited access networks limit access and by doing so can ensure that resources/infrastructure grow fast enough to provide good service levels. Well, that's the theory anyway - an awful lot of limited access networks still have piss-poor performance. But, in theory, the limiting of access means that there's money available to buy infrastructure and thus keep the network running smoothly as it grows. The downside is you end up with some kind of authentication system, by definition, which serves to limit access to the network.

So far, this is all tediously boring. But bear with us, the good stuff is coming up...

"Go Away, You're Not Allowed!"

Let's stick to limited-access networks, the kind that require some kind of authentication system. And let's stick to "VPN services," which is to say private encrypted networks that are designed to provide subscription-based service to "consumers" (as opposed to businesses - an odd term, but that's what gets used in English, alas). Essentially everyone in the "VPN industry" uses tools - VPN tools - to handle the encrypted connections within their network. Just as importantly, everyone uses these same VPN tools to handle network authentication. Makes sense, right?

Actually, not at all.

Step back from things for a minute, if you will: Virtual Private Network - VPN - tools were engineered and created to facilitate a very clear and very well-defined use-case scenario. That is a "mobile employee" - someone working from home, or on the road - who wants to connect to a corporate network and make use of stuff on that network. Name the protocol: PPTP, IPSec, OpenVPN... they were all created with this corporate-worker use scenario in mind. Sure, they can do other things - connect two servers on the internet, for example - but the basic assumption has always been that of the remote worker and the home office.

And in that scenario, if you're the sysadmin running that office network, you've got a couple of really big security issues to think about. One, you want to make sure the traffic back and forth with your remote workers - the packets going out over the "public internet" - is encrypted and secure, so that someone can't sit there bump-on-the-wire style and read your Valuable Corporate Secrets as they go whipping by. Two, you want to make sure that the person connecting to the network is authorized to connect to the network - currently, in realtime. You want to make sure that Janet is Janet - the sales genius Janet, not someone pretending to be her to steal her sales leads from the customer database. And you want to make sure that, if Janet is fired, her network access can be easily and irreversibly revoked - right now.

Still boring, right? Yep, but if you're reading closely it's likely you've already had the "AHA!" moment. Let's spell it out...

Using these VPN tools - and their implicit assumptions about network authentication - for controlling darknet access is a bit of square peg in round hole. More than a bit, really. In fact, the darknet use-case scenario is pretty damned different. In a darknet, there's no "secret network resources" you're trying to protect; instead, it's really a pass-through network that doesn't actually host anything (Tor "hidden services" are a bit different... but not really). There's no Corporate Secrets being protected.

And there's no pressing issue about ensuring that Janet isn't "impersonating" Janet, in precise terms. So long as someone's paid for access to the network, do you care if it's Janet... or James, or Jackie? Not so much, at heart, since none of them gets individualized access to specific network-based resources... because there are no network-based resources! It's all just pass-thru.

And there's no scenario of Janet suddenly being fired, and thus kicked off the network. Sure, some "privacy" companies have Terms of Service that go on for pages, and pages, and pages: if you "violate" them, they say they can immediately revoke your network access - fire you, basically. But if you're paying a "privacy" service to keep you private and that service is spying on you to see if you're following their rules... well, you're already off in the brambles and need to fix that first. Apart from that, you pays your subscription and you gets your access. Sure, if you don't pay to renew, your subscription runs out - but that's not like Janet suddenly (and unexpectedly) being fired, and thus being booted off the network.

Yeah, you can see where this is going now...

"Don't Tell Me Who You Are... I Don't Need To Know!"

What's the best way to keep a secret? Don't ever tell anyone. Done - secret is safe.

The big benefit of Tor - of any open access network - is that there's no reason for the network to be poking it's nose into who you are, as in specifically what real-life human you are, where you live, what your billing address is, and all that. Open access: don't need to know that. And, indeed, Tor doesn't ask - goes to some lengths to be sure it cannot, in fact, know who you are. Which really increases the security of things, from the network user's perspective: it's a great way to keep a secret, because you never tell anyone who you are in the first place.

"VPN service" companies - limited access darknets - don't work like that. They demand to know who you are... since they are limiting your access, based on whether you've paid or not. Then, they promise not to tell anyone who you are - except if they cross their fingers behind their backs, and say they will if they really feel like it. Or they say they won't, and just plain lie - telling people anyway. Or they screw up, and allow themselves to be pwned... thus spilling secrets about customer identity. It's an intractable problem. As the Grugq said recently in a discussion with us on Twitter...
Fair enough... buuuut wait. Is there any reason why a darknet - even a limited access darknet - actually needs to know who you are?

Nope, none whatsoever.

I'm Not An Office Drone - I'm An Internet Free Spirit

Yeah, the network needs to know that you're a paid-current subscriber. But that is not the same thing as knowing your identity - not at all. You're not Janet, working from the road on your big sales crusade - you're using a darknet to stay secure & private, ffs! The details of your financial transaction have absolutely nothing to do with your ability to access the network, or not - apart from a binary choice between whether access is allowed, or not.

If you look at how "VPN services" authenticate people for network use, that's not at all how things work. They all - each one of the dozens (hundreds?) of me-too VPN companies - simply grab the built-in authentication widgets of VPN protocols, and off you go. Those widgets, recall, were designed with Janet in mind... and as such they go to great lengths to be very sure that you are who you say you are. Authentication, old-style: prove you're Janet, or you can't use our network.

No. No, no, no, no, no! That's all wrong.

This is not how it should be done. Not at all.

"Ask Us No Questions, We'll Tell You No Lies..."

We don't want to make it seem like we're exempt in these criticisms, just to be clear. The old Cryptocloud VPN network used email address as network ID (!!) - which pretty much closes the circle and shows that all of us got this wrong, right from the beginning. Indeed, back in 2008 when Cryptocloud helped create the "VPN industry" as it exists today, we actually made the decision to use full-scale certificate-based, public-key, DH-enabled client authentication as the basis for our network connection procedure. Seemed like a good idea at the time; heck, read the OpenVPN manuals & this is what they have to say about the subject:
Don't require client certificate, client will authenticate using username/password only. Be aware that using this directive is less secure than requiring certificates from all clients.
More security is good, right? Well, yes... but that assume you're Janet. Alot of that "security" that certificate-based authentication implements is actually making sure that you are who you say you are... which is exactly what you don't want to tell a darknet in the first place.

Eliminate the Middleman

Man In The Middle (MiTM) attacks are a real, verified, seen-in-the-wild risk to users of VPN-based network privacy services. On the surface of things, you might think that doing a big, certificate-based authentication to the network will help protect against MiTM... and you'd be partially right.

Specifically, the scenario we actually want to protect against in darknet authentication is that an attacker manages to convince clients connecting to the network that they're connecting to the network... when, in fact, they're connecting to the middleman. This would allow the middleman to capture plaintext network traffic, breaking security. A subsidiary threat vector is a MiTM attack that targets an existing secure session, slipping into the middle of it without either side knowing it's happened (for technical reasons, this tends to be substantially more difficult than a "spoof" of the original session setup).

Protecting against these actual threat vectors requires that the server prove it's legitimate- the attacker would have to fake that he was the secure network server, and trick the client into connecting. The reverse scenario - tricking the server into believing a client is a "real" client when in fact it's not doesn't actually make any sense at all. Worst-case - and it's not very "worst" - is that someone tricks the network into allowing access without paying for access. No security is broken, and no network user data is at risk. So, there's no use confirming that a client is a specific client with a specific identity - it adds no security to anything at all, and actually decreases privacy in the macro sense.

We do want to ensure that a client doesn't "switch identities" mid-session, as that would allow a hijacker to take over a session and perhaps get access to private data. However, doing so is a different cryptographic challenge than verifying a specific identity as it exists in some remote database. Fortunately, ensuring that mid-sessions switches doesn't happen is straightforward using modern, well-tested cryptographic tools.

Protecting against the well-documented attack vector of MITM doesn't require client identity authentication, and doesn't make the network any more secure for actual customers.

Network Tokens - The Future of Darknet Authentication

In hindsight, the right way to do this is both obvious and entirely different from the way it's currently done in the "VPN industry." The right way to do it is via what we call "Network Tokens," or NTs for short. NTs are cryptographically-generated passkeys that encode in their mathematical structure only the information that confirms the NT is valid for a certain defined period of time. That's it.

NTs replace "username," password, email address... all the other left-over flotsam & jetsam of Janet's work-from-home use scenario. NTs are the handshake that lets the darknet know a given network session is authorized - and that's all it lets the network know.

Finally, NTs have no explicit connection to any financial or billing system. As operators of the darknet, cryptostorm need not know that information. We don't want to know, in fact. How you, as a customer of the network, know that cryptostorm isn't making that connection (between NTs and your financial/payment info)? Simple: buy the NT from someone other than us.

Because the most secure model for darknet administration fully decouples payment data from network authentication (more formally, it ensures there is a non-reversible/one-way transform of the former into the latter), the right way to do things is for someone other than cryptostorm to sell the NTs. So that's what we've done. :thumbup:

NTs will be provided, in bulk, to resellers who then distribute them to folks for use on the network itself. That way, cryptostorm simply doesn't know who purchases which NT - we can't, as those actual sales are done by the reselling partners rather than us. Sure, we might be able to figure out that a given NT was part of a given batch sent over to a given reselling partner... but that's it. We could call up the reseller and demand they tell us who bought a specific NT - but good resellers will be teams that are trusted not to tell us, not to keep those data in the first place, or both.

Trust - But Verify

It's a different way of thinking about - and implementing - a private network. Using NTs goes against the assumption that doing a fancy, sophisticated, prove-who-you-really-are authentication makes things more secure for network users. We've been thinking about this question for years, and we've been convinced for some time that there's a better way to do things. But it's not been so obvious how to do it, until recently. In truth, some of the final Eureka momentum has come from watching how the bitcoin "blockchain" model scales in the wild.

Finally, this year, we started to see how to do it better.

As we helped work on the "torsploit" analysis & studied the ways in which certain attackers (<cough>NSA<cough>) are going after Tor's security strong points, we realised that there's a way to capture a big chunk of the extra privacy afforded by open access darknet authentication... if you're willing to throw out all the old assumptions that have sat at the core of the "VPN industry" since 2007.

So we threw it all out, and started with a blank piece of paper.

The result is Network Tokens. Never again do customers of a secure network need to make a trade-off between genuine anonymity, and full network performance. Now, it's possible to have both - without sacrificing either. All it takes is the willingness to reconsider everything you've previously assumed, re-evaluate what's possible, & rebuild a new network from the ground up.

As we move from this pre-launch phase into full production status, prior Cryptocloud customers will receive their NTs for access to the new darknet. Shortly thereafter, folks who have added their names to the queue for network access will be provided with links to resellers who have NTs available for sale; they're limited based on network resources, so it's first-come, first-served.

Over time, we'll be doing our best to ensure the NT model of network access is as elegant, customer-friendly, and streamlined as it can possibly be. We don't accept the need to trade off elegance for real security; indeed, we know that sometimes the two go hand-in-glove... just like with the NT model itself. As we fine-tune the NT model, we know our customers will continue to help us find ways to make things better.

the cryptostorm darknet

There's no such thing as a perfect system. There's always the possibility to improve, and what was the best thinking - and best implementation - of years past is often left behind by new, more effective ways of getting things done.

Network Tokens are one way that the cryptostorm team is forging a path forward to more secure, more elegant, more robust network privacy service. We're eager to see how other security experts take the general concept and refine, expand, and evolve it further - it's a collaborative process, and we've always been part of the community's collective work towards better tools for protection against all forms of surveillance threats online.

Now, more than ever, it's time for seriously forward-focussed approaches to network privacy service. Relying on old tools, old models, and old assumptions in today's post-Snowden world just won't do.

  • ~ cryptostorm_team

Re: Network Tokens - darknet authentication done right

Posted: Sat Aug 31, 2013 6:01 am
by marzametal
What a read!

shared secrets & VPN vulnerablilities

Posted: Fri Sep 06, 2013 6:48 am
by Guest ... rveillance
{Schneier's Guardian article is also available here in the cryptostorm forum, for convenience ~pj}

in this article a statement is made:
"TAO also hacks into computers to recover long-term keys. So if you're running a VPN that uses a complex shared secret to protect your data and the NSA decides it cares, it might try to steal that secret. This kind of thing is only done against high-value targets."
Now does the token system have any amount of protection against this or similar attack vectors?

Re: Network Tokens - darknet authentication done right

Posted: Fri Sep 06, 2013 11:49 am
by Guest
Could use more tecnical explanation.

What stops somone from copying the token from your email? consequences if so?
What if you get rouge resellers who copy tokens for spying or just double sell the same tokens?
How do the servers verify themselves to the client? Is this still OpenVPN based?
How does this protect differently/better then a standard user/pass/cert setup?
Do the keys still roll over periodically?
Perfect forward secracy?
Are you doing any direct sales, or is it all reseller based?

Maybe I missunderstand, but the whole token thing sounds like it's a business decision to shuffle/outsourse record keeping acountability; really not sure what to think about it. Would a reseller be legally obligated to keep a record of the token id? -theorectically, what happens here, in any case.

Re: shared secrets & VPN vulnerablilities

Posted: Fri Sep 06, 2013 3:28 pm
by Pattern_Juggled
Guest wrote:Now does the token system have any amount of protection against this or similar attack vectors?
In a word: yes.

(although it's not, in a formal systems sense, the tokenized nature of our model that actually protects against that class of attack vectors...)

The key issue here is ephemeral session keys.

In our implementation of token-based authentication, we're expressly rejecting any effort to individually authenticate the client making that specific connection. The only thing we check is the authenticity of the token itself; there's no "identity confirmation" framework whatsoever.

As such, what we're discussing is the set-up & maintenance of an ephemeral network session. Doing that could be done via a permanent shared-secret mechanism: let's agree on a symmetric key and then we'll keep using that key for this and all future sessions. But that would be extraordinarily dumb.

Much more appropriate - and really, more obvious - is the use of transient session keys to secure the actual VPN connection. Indeed, OpenVPN will automatically cycle session keys hourly, unless one goes to some effort to stop it (which of course we don't do). Thus there's no "master key" or "permanent shared secret" to steal, from any server anywhere. Rather, every key is temporary and stealing it would only allow access to that particular session fragment (the likely attack scenario here is an adversary who records the ciphered packets of a longer-duration session, and then somehow gets access to one of the transient symmetric keys in the future: with that key, they can only decrypt the fragment of the session that was keyed temporarily via that particular key... which, of course, is never stored past the end of that ephemeral session fragment in the first place)

Mostly the take-away on this is that symmetric cryptography works. Indeed, here's Schneier himself saying as much:
"Prefer symmetric cryptography over public-key cryptography."
That's a pretty fucking big deal, if you'll excuse my language.

Many of us came into the world of cryptography in part because we were fascinated by the properties of asymmetric-key/public key cryptography. There's something... almost magical about the way that RSA/DH/ECC are able to do what they do. It doesn't seem like something that this universe is really going to allow - and yet it works. And works well.

But indeed the underlying truth is that symmetric keys kick ass, and always have. Use a long enough cipher containing enough entropy, via any of a whole basket full of well-studied symmetric algorithms, and the resulting datastream is provably secure against brute-force attacks of all manner (within the constraints of the heat-death of the universe, &c). These are known instantiations of NP Completeness, in other words.

Public key crypto's utterly cool, elegant addition to this foundation comes at a price: it's a bit more delicate. Mess with it in just the right ways, and it weakens... badly. Worse, the weakening is really difficult to notice ex ante; of course, ex post facto it's obvious. Which isn't much help at all.

In contrast, the algorithms used in symmetric encryption - whether bloc- or stream-based - are workhorses. They work. If they fail, they tend to fail publicly so. They aren't so subtle, nor so elegant.

And Schneier's saying that, given how clever and well-funded and deeply-entrenched the NSA is out there, it's probably better to move towards symmetric techniques unless there's a really specific reason to use a PKI-based technique.

We couldn't agree more!

Indeed, we've concluded that authenticating folks to a "consumer VPN service" such as cryptostorm (sort of... essentially... more or less is) does not require the magic of public key cryptography to be done right. Rather, streamlining things down to symmetric/transient ciphers is safer, better, less complex, and thus more reliably secure.

There's still a bit of certificate-based stuff going on. Specifically, clients still ask the server to prove it's who it claims to be - as a component of anti-MiTM protections. That's not actually public key cryptography; it's more of a "vouch for me" kind of action, that happens to make use of a little piece of the PKI universe's capabilities: a CA (certificate authority) "vouches" that the server is presenting a key that matches the key it's got on file with the CA.

Apart from that, no public key crypto. It doesn't add value, and thus it shouldn't be there.

(one could do this in auth models other than tokens - or, more formally, the set of auth techniques that don't require public key crypto is not limited to the sole example of token-based methods - and one could actually build a token-based model that forces public key elements into the session despite the lack of obvious value from doing so... but generally speaking, tokenized auth goes together with transient symmetric crypto like warm, soft bread goes with Gnutella :thumbup: )


Re: Network Tokens - darknet authentication done right

Posted: Sat Sep 07, 2013 1:53 pm
by Guest
So If the three letter vouyers got a hold of a copy of a token could they then mount a MITM attack, or otherwise defeat the privacy? if the CA is compromised?

The server cert check is unidirectional- how does that work? who is the CA? does the token replace the client cert?

Another question:
If a users browsing habbits are allready known- ie, they read the same news websites every day, usually in a predictable order. Can that information (the given signature of websites, at the time of encrypted transmition) be used to break the encryption? -solve for x.

Re: Network Tokens - darknet authentication done right

Posted: Mon Sep 09, 2013 3:57 pm
by Pattern_Juggled
Guest wrote:So If the three letter vouyers got a hold of a copy of a token could they then mount a MITM attack, or otherwise defeat the privacy? if the CA is compromised?
No. The token is much simpler that that. It simply gets the client onto the network. Someone grabbing a token simply gets free network access. There's no pot of gold at the end of that rainbow.

The entire structure of tokens is that they don't "vouch" for anyone's identity. They are useless for MiTM.
The server cert check is unidirectional - how does that work? who is the CA? does the token replace the client cert?
There is no client cert.

The client cert exists to authenticate the identity of specific clients. We don't want to know that - at all. We only want to know that a given network session is in the class of network sessions that have a valid connection token ("NT") available to them at session initiation. That's it.

CA parameters for server-side authentication are available menu-style. From the canonical documentation:
This is an important security precaution to protect against a man-in-the-middle attack where an authorized client attempts to connect to another client by impersonating the server. The attack is easily prevented by having clients verify the server certificate using any one of --ns-cert-type, --tls-remote, or --tls-verify.
In general, we follow the path of duplicative, publicly-verifiable publication of server keys - which really doesn't require or even benefit much from the old, centralized CA architecture at all... unless you think Comodo really does an excellent job of ensuring their signing chains are rock solid. Ha.

Unidirectional cert-based server attribution is easy - it's really a simple (nearly "degenerate") use-case for public key crypto concepts: here's a public key I have, prove to me that you're the person who issued that public key, and not some imposter. Hell, even a doofus like me could potentially code a little implementation of RSA(-ish) prime factorization concepts - from scratch - to implement this trivial example of public attestation of identity. That's 'cause there's no crypto related to this "public key" usage - it's just an attribution validation.
If a users browsing habbits are allready known- ie, they read the same news websites every day, usually in a predictable order. Can that information (the given signature of websites, at the time of encrypted transmition) be used to break the encryption? -solve for x.
You're sort of describing a "chosen plaintext attack," in a sense, and there's certain weaknesses in poorly-configured TLS implementations that make use of that kind of thing. Although, more specifically, you're simply talking about a staple of cryptanalytic technique for many hundreds of years: if you know the plaintext of the cipher stream, then you can (if you're clever) brute-force reconstruct the transform used to generate the encrypted text... and thus (in theory) have the entire system broken.

In practice, this usually boils down to how much plaintext one has available, and how many times one can feed the same plaintext through the cipher; all modern ciphers use random(-ish) initiation seeds/strings/nonces to thwart exactly these kinds of attacks - and whilst they aren't perfect, they do tend to drive up the needed plaintext to break a system by many orders of magnitude.

In the current case, of course, traffic is mux'd through the VPN exit nodes - so it's nontrivial to pull out session behaviour for individual network users with high confidence. Definitionally so, in fact.

"All Tomorrow's Tokens" - cryptostorm network auth

Posted: Mon Oct 14, 2013 2:45 pm
by cryptostorm_team
And without further ado, the tokens are on the wire...

If you're not sure what the heck a token is and why it matters, take a look at this thread - it's got the full backstory, theoretical underpinnings, & plenty of details. tl;dr is that tokens are the only thing required to access & make use of the cryptostorm darknet - there's no "username," no "password," no "customer database." None of that. Just a token, & you're good to go.

Getting ahold of a token isn't any hassle. There's two main options:

  • 1. Visit one of our authorised resellers via the authoritative index maintained at, and make use of the standard suite of creditcards for purchase;

    2. Use a cryptocurrency to purchase a token directly from the source - we support not only Bitcoins (click here to purchase) but a dozen more, specialised crptocoins such as litecoins (click here to purchase).

We've minted exactly 512 tokens to distribute to new network members. Once this first tranche has been distributed, we won't be minting additional tranches until we finish the production testing. Folks who have already requested an invite will receive first access to these minted tokens shortly; once that's been done, the remaining tokens (if any) will become available for additional new members. We don't know when we'll be minting the next tranche after this - hopefully not too long, but only when we're satisfied with the rollout & have deployed the next layer of network capacity in advance to handle increased traffic volumes from an additional tranche.

Existing Cryptocloud VPN customers are receiving complimentary tokens at no cost, by letting us know their subscription status via this form on our website.

Our first run of tokens are available on one-, three-, sixth-, and twelve-month flavours. Tokens don't renew; they expire and once expired they're done with. You don't "top up" tokens - the old one runs out, and a new one steps in. (yes, we're working on a way to make that re-up process elegant and streamlined so it need not be done manually - coming soon)

Also, your token doesn't start its countdown to expiry until you log into the network the first time. So if you buy it but don't get 'round to using it initially for a while, no worries - it won't go stale sitting on the shelf.

Let's speak plainly: nobody's ever done a token-based auth model for a secure network before. Our team has been working on a token-based auth model for more than five years, on and off. The past few months, we pushed all else aside and made it happen. We think it's worth it. No, we're damned sure it's worth it.

But it's not going to be a surprise if there's some hiccups in this beta rollout of tokens.

We've hardened things up top to bottom in terms of any potential security impacts from said hiccups, so that's not the point. But there might be some rough edges here and there when it comes ensuring the process with customers is super-smooth and efficient. Hopefully, our work has been able to prevent any such rough edges... but anyone who's built something truly new likely understands that no amount of prep work will ever shake out those last little bugs until you go into test production mode and finish the process there.

This is a beta rollout, in other words. Late-stage beta, but still.

Snags or questions, drop us a note at & we'll get you settled.

As always, if you're an activist & the cost of a token prevents you from making use of the network to keep your work secure, we'll hook you up. Email us, subject line "ACTIVIST SUPPORT," & we'll get you a token. If you'd like a batch for a fundraising project or... whatever, let us know. We'll do our best to help you out, although it might not be in this first tranche of newly-minted tokens.

Finally, if you're someone who would like to review the network for a media outlet, blog, or other such public outreach channel we're happy to provide a gratis token for you to test the network firsthand. Drop a note to our community outreach team, & include "MEDIA REVIEW REQUEST" in the subject line so we can get you set up right away.

That's about it, folks. Welcome to right way.
  • ~ cryptostorm_team

HOWTO: network access tokens & cryptostorm auths

Posted: Fri Oct 18, 2013 9:10 am
by cryptostorm_team
To make use of the cryptostorm darknet, you need a network access token. We usually just call them "tokens."

A token is a 20-byte, randomly-generated (using exogenous entropy) concatenation of the concepts of username and password. Or, put another way, a token is sort of like a SSH key (for those who make use of such things). Or, it's a nice long passphrase with plenty of unpredictable content... but it's set for you in advance, rather than set during some sort of "account creation" with cryptostorm. There's no "accounts" in the cryptostorm model.

What's the theory behind tokens, and token-based authentication? It's best to review the existing thread on that topic, which goes into some detail. In our security model, tokens replace client-side keys/certs (details in this separate thread) as well as customer-generated username/password combinations.

We "mint" tokens in-house, and distribute them to token resellers (and directly to network members, via purchase with established cryptocurrencies). Tokens expire after a set period of time; currently they come in one, three, six, and twelve-month flavours. Tokens only start "running down" towards their expiry date after they've been used the first time for a successful network login.

Tokens don't "renew." They expire, and a new one is acquired to continue network access. We're working on a wallet-based tool to automatically load tokens into the network access widget so it's minimal hassle. Right now, ctrl-c/ctrl-v (i.e. copy/paste) is your friend.

Using tokens for network access is pretty simple:
  • 1. Get ahold of a valid, non-expired token.

    2. Run this token through a SHA512 (no, not MD5, ffs!) hash function. There's a bunch freely available online (here and here, for example; handy test vectors here) although doing so client-side (here is our own Javascript version) is more secure. We'll add info on doing that in this thread, as we go. (our network access widget does this automatically, btw)

    3. This resulting string of bytes - exactly 128 bytes - is the "username" that gets handed to the cryptostorm network for session authentication. This is what gets passed "across the wire" to our exitnode authentication interface, to confirm you're authorised for network access. Your token never goes out plaintext.

    3b. In contrast, the old "password" field is set at a fixed value of: 93b66e7059176bbfa418061c5cba87dd. That doesn't change, as we don't actually use the "password" field as part of our security model. (the network widget auto-fills this vestigial field for you)

    4. Don't lose your token, as we can't replace it. We don't know who gets what tokens, and we don't want to know. We don't have a 'customer database' and we know nothing about network members. All we do is run the network, and mint tokens. All we see, network-side, is (SHA512 hashed) tokens come to our authentication interface. If they're legit, and haven't expired, that secure network session is allowed. That's all we need to know.

    5. You can't log in a bunch of different machines with the same token. We've talked alot about this, and likely will keep discussing it with our member community. But there's some serious security downsides to allowing the same token to get re-used across devices, and we don't think the concomitant benefit is worth it for customer security decrease it causes. We've priced tokens to be affordable, so if you've got a few different computers (or routers, or smartphones, or whatever) we suggest you procure several tokens and use one for each. Yes, we'll be doing some sort of "bulk" discounts for tokens, as time goes by.

    6. Cryptographically, tokens serve as the original handshake with the network. They aren't part of the actual guts of the secure transmission of packets during the network session. They just confirm to us, at the network level, that you're authorised to be on the network. And they're supposed to be "chunky" enough to make it tough for someone to MiTM you via several known attack models - more on that in threads specific to those threat vectors and the techniques we've deployed to defend against them. Session security (at the control channel level, which is what matters most to ensure symmetric keys are securely exchanged) is handled via TLS "perfect forward secrecy" (PFS) via Diffie-Hellman "ephemeral" discrete logarithm asymmetric key instantiation. More on that in threads here discussing the guts of our crypto engineering framework.

    7. Plug your token into your OpenVPN-based client of choice - or hand it to our network access widget, and it'll do the rest for you.
Lest we get typically long-winded, we'll stop here. That's what a token is: it's your "ticket for the ride" on our network. Perhaps think of it as equivalent to a paper ticket sold at amusement parks: with it, you can get on whatever ride, whenever you want to. It's value is in its ability to get you on the ride you want. Once you use it, it's spent. It's anonymous (if you buy it for cash, or from a reseller). It doesn't serve as some kind of "identity" for you, and it's not tied to an "account." It's just a ticket.

Tokens are the best way we've ever discovered to get folks onto a secure network with minimal knowledge-transfer of who network members are in real-life. We've worked hard to strip out any and all unnecessary complexity from this process, so that we focus all our efforts and attentions on the areas of the security model that truly matter in practical terms. This is a better way to do things.

Re: "All Tomorrow's Tokens" - cryptostorm network auth

Posted: Fri Oct 18, 2013 1:37 pm
by rocket
cryptostorm_team wrote:
Folks who have already requested an invite will receive first access to these minted tokens shortly; once that's been done, the remaining tokens (if any) will become available for additional new members.
I'll admit that I've been a bit busy with other matters this week so I missed this when it was posted four days ago. What's the go for those of us that registered as an existing member back in August, got the confirmation email but still haven't received a token?

Re: "All Tomorrow's Tokens" - cryptostorm network auth

Posted: Sat Oct 19, 2013 12:35 am
by cryptostorm_team
rocket wrote:I'll admit that I've been a bit busy with other matters this week so I missed this when it was posted four days ago. What's the go for those of us that registered as an existing member back in August, got the confirmation email but still haven't received a token?
We've just begun mailing tokens out today, and will continue over the weekend. To keep things most secure, we're doing so manually and that takes a bit of extra time - but it also means there's no automated systems that could behave unexpectedly.
  • ~ cryptostorm_team

Re: "All Tomorrow's Tokens" - cryptostorm network auth

Posted: Sat Oct 19, 2013 3:23 am
by rocket
cryptostorm_team wrote:
We've just begun mailing tokens out today, and will continue over the weekend.
Ah, my apologies. When I saw the date on the first post I had wrongly assumed you were at or near the end of this process.

/Token now received.
//Crawling back under rock.

Re: "All Tomorrow's Tokens" - cryptostorm network auth

Posted: Sun Oct 20, 2013 11:35 am
by marzametal
Same here!

Re: "All Tomorrow's Tokens" - cryptostorm network auth

Posted: Sun Oct 20, 2013 2:51 pm
by cryptostorm_team
^^ tokens PM'd.

Re: "All Tomorrow's Tokens" - cryptostorm network auth

Posted: Wed Oct 23, 2013 11:12 pm
by Guest
I guess you all have alot to do but so far no token sent my way. ;)

Re: "All Tomorrow's Tokens" - cryptostorm network auth

Posted: Wed Oct 23, 2013 11:14 pm
by jdurne
I guess all of you have alot of stuff going on but so far no token sent this way. ;)

Re: "All Tomorrow's Tokens" - cryptostorm network auth

Posted: Fri Oct 25, 2013 3:35 pm
by maverickshaman
Ditto here! Did get an email saying I would receive it in the first round... yet to receive it though.
No hurry still, I know you guys are busy getting the kinks worked out!

More power to the storm!

Re: cryptostorm: All Tomorrow's Tokens... or, auth done righ

Posted: Tue Dec 31, 2013 2:06 am
by Guest
Can someone explain why the token I receive must be hashed before it is used? The link to "hashing" inserted in the post went over my head.

Thanks in advance for the help.

Re: cryptostorm: All Tomorrow's Tokens... or, auth done righ

Posted: Thu Jan 02, 2014 1:34 pm
by DesuStrike
Hello Guest,

just put your token into this nice little tool, push the button and you got yourself the hash you need to connect!


Re: cryptostorm: All Tomorrow's Tokens... or, auth done righ

Posted: Thu Jan 02, 2014 8:28 pm
by Guest
Thank you, but I was curious about the reason behind hashing the token. The way understand hashing is it encrypts the token into a fixed length output.

I understand why a website would want to store passwords as hashes, because if stolen they can't reverse the hash to obtain the password.

But I don't understand why a user would hash the token and then use the hash to login into the tunnelblick session.

What difference is there between using the token and the hash of the token to login?

Thanks in advance
DesuStrike wrote:Hello Guest,

just put your token into this nice little tool, push the button and you got yourself the hash you need to connect!


Re: cryptostorm: All Tomorrow's Tokens... or, auth done righ

Posted: Mon Jan 06, 2014 8:37 pm
by DesuStrike
Thank you, but I was curious about the reason behind hashing the token.

{Sorry for the late reply but I hope this will answer all your questions. This is an excerpt from an email conversation between Pattern_Juggled an me.

Code: Select all

This is why we encourage people to buy tokens from independent resellers
- in that way, we never see the purchase transaction and, by formal
proof, never know the identity of customers. Our goal is to move most or
all token sales over to resellers as much as possible.

The key to the token model is that the token itself is not used anywhere
in our production system - it is always the hashed token. So, even if
someone were to infiltrate an exitnode, secretly sit and have /root
access to all network activity, they get only the hashed token - and to
'reverse' that to the token is mathematically not feasible (an NP
Complete-class problem).

There does exist the connection between hashed token and physical IP -
but to take that connection back to a "real person" is many steps of
not-very-solid math and inductive assumptions. It would certainly never
hold up in court.

Members that do not want to "trust" us with their identity - which is a
good thing! - can buy with bitcoins or via reseller, so we never have
any idea who they are. This removes trust as a factor - and indeed for
many of our members, we know exactly nothing about them. That is good.
It is the goal of the model.

Re: cryptostorm: All Tomorrow's Tokens... or, auth done righ

Posted: Tue Jan 07, 2014 11:07 pm
by Guest
Thank you. That makes sense. I appreciate your time.

Re: cryptostorm: All Tomorrow's Tokens... or, auth done righ

Posted: Tue Mar 11, 2014 3:05 pm
by ktorn
Wait, are you guys selling cookies for VPN auth? Ingenious. :lol:

Re: cryptostorm: All Tomorrow's Tokens... or, auth done righ

Posted: Sat Aug 09, 2014 7:36 pm
by odb
Installed, have key....keep hitting "mute triggered" or "exit due to fatal error" I follow instructions to go to start menu and select tap window...etc etc. There is no tap window.
I tried dl openvpn to see if that would work. Keep hitting brick walls.
Help plox :crazy:

Re: cryptostorm: All Tomorrow's Tokens... or, auth done righ

Posted: Mon Aug 11, 2014 11:12 am
by cryptostorm_support
Greetings, odb.

Could I get you to send a support email to with a description of your issue and a copy of your logs? If you'd rather send me a PM with the same information that would work too :)


Re: cryptostorm: All Tomorrow's Tokens... or, auth done right

Posted: Mon Dec 29, 2014 4:32 am
by parityboy

Necro but I don't care. :P I have a couple questions concerning tokens, and so far I've not seen them asked.

1) What is the theoretical limit on the number of unique tokens which can be minted using your model?

2) What is the percentage chance of a collision, a la MD5?

Re: cryptostorm: All Tomorrow's Tokens... or, auth done right

Posted: Mon Dec 29, 2014 8:22 am
by Fermi
1) What is the theoretical limit on the number of unique tokens which can be minted using your model?

2) What is the percentage chance of a collision, a la MD5?
On 1):
A token consists out of 4 groups, each group consists out of 5 characters: [a-z], [A-Z], [0-9] > 26 + 26 + 10 = 62, leading to 62^20 or 2^119.08392 different tokens.
A number which will keep Cryptostorm going for a while :P

On 2):
A collision is theoretically possible, but if we can find a collision induced by the 'token pool' of 2^119.08392 tokens, it would actually mean that SHA-512 can be considered as broken, as 2^119.08392 is well below 2^(512/2) = 2^256
One could check, but next to the CPU power, one would need 2^(119.08392 + 9 - 3 - 10 - 10 - 10 - 10)TB = 2^85.08392 TB = 4,100266346×10^25 TB to only store the 512 bit hashes.

Thought: as the distributed tokens do not appear to be sequential, there must be some randomness during token creation, of course collisions on this level are easy to check.


Re: cryptostorm: All Tomorrow's Tokens... or, auth done right

Posted: Mon Dec 29, 2014 11:27 am
by Fermi

A collision will not lead to a security issue, and therefore not facilitating MitM, impersonation, ... attacks. This because the hashed token isn't involved in the encryption process. A hashed token is just a means to be able to access the Cryptostorm network, it isn't even linked to a physical user.
In the unlikely case of a collision, the colliding users will experience auth issues during connecting / key renegotiation.

Support will not expect colliding hashes, but consider it as a case of a leaked token, leaving the opportunity to proof sha-512 as broken unnoticed ... ?



Re: cryptostorm: All Tomorrow's Tokens... or, auth done right

Posted: Tue Dec 30, 2014 4:24 am
by parityboy

Many thanks for the reply. One more question question, which I just thought of: not so much the chance of a SHA512 collision with two different tokens, but more a case of minting two or more identical tokens? I know nothing of the actual minting process but I will assume that each single character in a token is generated separately and then concatenated into a group of four, which are then concatenated into a token string.

Would this be along the right lines?

Re: cryptostorm: All Tomorrow's Tokens... or, auth done right

Posted: Tue Dec 30, 2014 10:22 am
by Fermi

I also don't know the internals of the minting process, but there are algorithms out there that are able to handle this kind of issues.
Sure this is handled properly.


Re: cryptostorm: All Tomorrow's Tokens... or, auth done right

Posted: Tue Dec 30, 2014 5:03 pm
by parityboy

I might take an hour and write some token minting code myself, just to see if I can do it. :D

Re: cryptostorm: All Tomorrow's Tokens... or, auth done right

Posted: Mon Jan 04, 2016 10:09 pm
by Enorniel
How do you handle the anonymity at the server level ?

As far as I understand, OpenVPN server decrypt and re-encrypt packets to forward them correctly. How do you avoid the owner or anyone having access to an OpenVPN server in the network to read packets ?

Re: cryptostorm: All Tomorrow's Tokens... or, auth done right

Posted: Tue Feb 16, 2016 3:19 pm
by ripl
Do you also use methods that add further layers of pseudo-anonymity, or privacy enhancing measure(s) on top of the protection layers they provide (VPN network access) ?

yeah .. about time HSM modules came into usage.

Re: cryptostorm: All Tomorrow's Tokens... or, auth done right

Posted: Sat May 27, 2017 9:52 am
by harry56
I completely agree, and I hadn't heard of 'GRE tunnels' before reading the 'stream of consciousness' README on voodoo's github. It's fundamentally simple - without the bs every single other VPN provider 'claims' to provide. You (or whoever wrote it) did so transparently - open source - so cryptostorm has my trust and respect.