Replies to recent interviews

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
Posts: 133
Joined: Sat Jan 26, 2013 4:31 am

Replies to recent interviews

Post by cryptostorm_support » Sat Feb 28, 2015 9:35 pm

{direct link:}

From time to time, we are asked to reply to questions in the form of "interviews" submitted to our team. Here's some of our replies, which may be interesting reading in a standalone format...

What VPN encryption do you offer for your users?
  • auth SHA512
    # data channel HMAC generation; substantial improvement over default digest-generation algorithm.

    cipher AES-256-CBC
    # data channel stream cipher methodology; not currently known to be formally vulnerable to any theoretical or practical attacks.

    replay-window 128 30
    # settings which determine when to throw out UDP datagrams that are out of order, either temporally or via sequence number; this is a test configuration parameter not yet put into production.

    tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
    # full PFS via selection of ephemeral Diffie Hellman key regeneration & exchange for use in asymmetric control channel renegotiation.
    # for details on this discrete logarithm-based alternative to elliptical-curve DHE key generation/synchronisation, see .
    # We're still experimenting with ECC-based PFS, but until we develop a deeper confidence in the mechanism for choosing & implementing curves within standard ECC frameworks, we're not deploying
    # see this resource for full details: .

How many connections are allowed per user?
  • We don't do "user"-based network authentication; we make use of network access tokens to manage this process, and as such one token enables one concurrent network session. We have not become comfortable with the MiTM risks of multiple concurrent sessions in a security-intensive framework such as this.

Do you have a bandwidth usage limit?
  • Nope.

What amount of uptime can you guarantee your users?
  • Anybody who "guarantees" certain uptime levels is either a liar or a fool. We are neither. Additionally, our HAF-based cluster framework ensures that single points of failure ("servers") are never uniquely mapped to "--remote" directives within our session parameters as pushed to connected network members. Thus, if a node goes down, that session will immediately reconnect to either another node in the cluster, or in the case of folks using our network-wide balancers (smoothed or dynamic), or another node selected non-deterministically from any available in the network at the time.

    Our cluster-based system status is reported via a status page - - powered by pingdom: we don't make up fake "stats" as do so many "VPN companies." Instead, our data are independently collected, tracked, and reported by pingdom.

In which countries do you have servers?
  • We structure our network based on clusters, not "servers." Currently we've clusters in the following geo-locales:
    • Canada-East
      Lisbon (Portugal)
      London (England)
      Frankfurt (Germany)
      Paris (France)
      Reyjavik (Iceland)
      Moscow (Russia)
      Singapore (Singapore)
    Every machine in our network is a dedicated, from-the-metal server we adminiser ourselves - we never use insecure VPS "servers" in production context. Each of our nodes is running a grsec-upgraded Debian kernel. We self-compile all core cryptographic libraries from currently-pushed SRC.

What kinds of logs do you keep on users and their activity? How long are these logs stored in your system?
  • None. Details:

    We also don't have purchasing/financial information connected in any way to real-life identity of our network members; our token-based authentication system removes this systemic connection, and thus obviates any temptation to "squeeze" us for private data about network membership. We quite simply know nothing about anyone using our network... save for the fact that they have a non-expired (SHA512 version of) token when they connect.

    Indeed, with our speed-capped cryptofree version, there's not even any tokens.

In which country is your business located? How does the law in that country affect user information?
  • We're a decentralised project, with intentional separation of loosely-integrated project components. Much of our financial processing runs through a payments-focussed sibling entity based on First-Nations sovereign territory geographically located within the province of Québec, itself loosely encased within the federal confines of the country of Canada. We own no intellectual property, patents, trademarks, or other such things that would require a corporate entity in which ownership could be enforced by the implied threat of State-backed violence; all our code is published and licensed opensource.

    However, we've concurrency in financial operations and make use of parallel payment processes under distinct organisational control in two other jurisdicational locations: France and Iceland. Thus, we can walk away from 2 of the 3 simultaneously with no impact to ongoing financial operations for the network.

    As we hold no member information - no "customer database," no payment data (all actual card-processing is done via gateway'd third-party service providers; we never run, see, store, process, or have any interactions with creditcard payment details for any of our members, ever), and nothing else relating to our membership, there's no corporation that "owns" our customers. Which sounds really creepy anyway, to be honest.

    There's alot of shameless bullshit when it comes to "jurisdictional jiggery" in the "VPN industry" in recent years. Pretending to be based in the Seychelles when you're actually a couple of guys living in Austin, Texas isn't going to fool an adversary who has even a small fragment of a clue at their disposal. That kind of thing is intended only to dupe customers with lies and false promised of magical security... we don't play that game.

    We have a core team of actual human beings that do the work behind the project (as well as a broad, loosely-connected group of supporters and colleagues worldwide who pitch in to make the project what it is today). They live physically in places around the world. It's likely the big Intel agencies know exactly where and who we all are - that's just a reasonable assumption. We're not involved in any illegal activity as a team or as individuals, and we're not posturing as if we're major items of interest in the international national security apparatus. That said, we don't broadcast our identities or locations, as human beings, because that simply increases attack surface exposure for less-resourced adversaries of the project itself.

If you are presented with a court order to identify an active user, what steps are taken to identify them?
  • We can't identify "users," as we've no idea who they are. So that's not been an issue - we've never received such an order, and really don't expect to get too many in the future as they're unlikely to result in any actionable data being made available. One might as well subpoena some random person walking down the street to demand they identify Satoshi Nakamoto. Useless.

If you receive a DMCA notice, what procedures do you have in place to deal with that issue?

How do you determine if a user is abusing your service? What happens once an abusive user is identified?
  • Um, never happened. Not sure what "abuse" would actually involve, and as we don't have "users" we'd not have any way to block someone's network access in functional terms. Here's our Terms of Service.

How is file sharing treated? Is it allowed? Why or why not?
  • We are port-, protocol-, application-, and location- (geographical & logical/topological) neutral in our routing of packet data.

What payment methods do you accept?
  • Pretty much every cryptocoin (bitcoins, litecoins, namecoins, darkcoins, zetacoins, feathercoins, etc.). All creditcards. We can do cash-mailed payments & have done them before. Currently deploying interfaces with Google Wallet, Amazon Payments, GoPay, and TeliPass. We've custom-engineered about every imaginable payment mechanism, if needed, in the past.

    Oh also we've a bunch of token resellers who have their own payment capabilities, etc.
cryptostorm_support shared support team forum account
PLEASE DON'T SEND PRIVATE MESSAGES with support questions!
--> 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! validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email:
live chat support: #cryptostorm

User avatar
Posts: 133
Joined: Sat Jan 26, 2013 4:31 am

Re: Replies to a recent interview ~ additional replies

Post by cryptostorm_support » Sat Feb 28, 2015 10:30 pm

1. Do you keep ANY logs which would allow you to match an IP-address and a time stamp to a user of your service? If so, exactly what information do you hold and for how long?
  • {see above}

2. Under what jurisdiction(s) does your company operate?
  • {see above}

3. What tools are used to monitor and mitigate abuse of your service?
  • {see above}

4. Do you use any external email providers (e.g. Google Apps) or support tools ( e.g Live support, Zendesk) that hold information provided by users?
  • This is an excellent question, and the answer is no. All such correspondence is self-hosted (with the obvious exception of bitmessage-based communications, of course).

5. In the event you receive a DMCA takedown notice or European equivalent, how are these handled?
  • Our choice is to reply to any such messages that are not obviously generated by automated (and quite likely illegal) spambots. In our replies, we ask for sufficient forensic data to ascertain whether the allegation has enough merit to warrant any further consideration. We have yet to receive such forensic data in response to such queries, despite many hundreds of such replies over the years.

    Silence speaks loudly.

6. What steps are taken when a valid court order requires your company to identify an active user of your service? Has this ever happened?
  • {see above}

7. Does your company have a warrant canary or a similar solution to alert customers to gag orders?
  • We have been involved in the technical and theoretical work of developing the concept and implementation of warrant canaries since prior to their currently-seen popularity as a marketing tool. Indeed, we coined the term "privacy seppuku" itself, which is a closely related subject.

    Unfortunately, many implementations of "warrant canaries" we see recently are terribly flawed both in conceptual foundation and in real-world application. This topic is perhaps a bit long for an interview reply, but we can say that doing a flawed warrant canary is worse than doing nothing at all, as it provides mere "security theatre" and encourages false confidence.

    Legitimate canaries are based on robust cryptographic signing systems, dead-man style "inaction is action" triggers, and blockchain-based writes to ensure corruption of process is not trivially easy for an attacker to accomplish. These systems are not terribly complex to implement and maintain, but doing so requires a substantive understanding of the theory behind canaries, as there are (as yet) no pre-packaged tools to do so available.

    We are currently in development of a blockchain-based identity, code, and project integrity validator system that has as one component what can be described as a canary-style capability. Initial steps on that can be seen in both our and identity validators, which together provide dual-blockchain (BTC & namecoin forks, respectively) redundancy authenticating our relatime control over website, domain, and DNS resources across multiple online assets.

    We further authenticate all distributed binaries via multi-algorithm hash 'fingerprint' postings in multiple redundant channels, to mitigate the real-world threat of corrupted binary distribution. Next steps for this include so-called 'reproducible build' recipes to supplement our published code on github, and thereby ensure integrity of compile is matched to integrity of binaries. Our next step here is 'chain-based write-outs of code signatures for distributed binaries, as well; the utterly useless state of conventional, CA-validated code signing mechanisms is obvious enough that we feel we need not explain why we don't bother with it, meanwhile.

    Down the road, we're looking to do so-called Merkle Root signatures of our node OS fingerprints, written out to the two respective 'chains. The work keybase has done in that area is inspiring, and we are relatively confident we can enable forms of independent verifiability via remote process without endangering node integrity. That's an ongoing project for us, but one we feel strongly about supporting.

8. Is BitTorrent and other file-sharing traffic allowed on all servers? If not, why?
  • {see above}

9. Which payment systems do you use and how are these linked to individual user accounts?
  • {see above}

10. What is the most secure VPN connection and encryption algorithm you would recommend to your users? Do you provide tools such as "kill switches" if a connection drops and DNS leak protection?
  • We only support one cipher suite on-net, per reply above. Offering "musical chairs" style cipher suite roulette is bad opsec, bad cryptography, and bad administrative practice. There is no need to support deprecated, weak, or known-broken suites in these network security models; unlike browser-based https/tls, there are no legacy client-side software suites that must be supported. As such, any excuse for deploying weak cipher suites is untenable.

    Everyone on cryptostorm receives equal and full security attention.

    There are no "kill switch" tools available today that actually work. We have tested them, and until we have developed tools that pass intensive forensic scrutiny at the packetized/NIC level, we will not claim to have such. Several in-house projects are in the works, but none are ready yet for public testing.

    We take standard steps to encourage client-side computing environments to route DNS queries through our sessions when connected. However, we cannot control things such as router-based DNS queries, Teredo-based queries that slip out via IP6, or unscrupulous application-layer queries to DNS resolvers that, while sent in-tunnel, nevertheless may be using arbitrary resolver addressing. Once again, we're working on tools to mitigate these risks, but no currently tools or frameworks are 100% effective in doing so. We are saddened to see others who claim they have such "magical" tools; getting a "pass" from a handful of "DNS leak" websites is not the same as protecting all DNS query traffic. Those who fail to understand that are in need of remedial work on network architecture.

    As we run our own mesh-based system of DNS resolvers, "deepDNS," we have full and arbitrary control over all levels of DNS resolution presentation to third parties. Indeed, on-cstorm visitors to "DNS leak" websites see a message directly from cryptostorm, embedded in the results presented... this is the level of expertise we are employing as we work towards improved member security.

11. Do you use your own DNS servers? (if not, which servers do you use?)
  • We have constructed a mesh-topology system of redundant, self-administered secure DNS resolvers which has been collected under the label of deepDNS. Rather than simply forwarding DNS resolution queries on to other outside layers for reply, deepDNS is a fully in-house mechanism that keeps all query data (and metadata) within cryptostorm exclusively.

    Further, deepDNS fully implements the namecoin-based DNSchain resolver architecture for openNIC-housed TLDs including .bit - which allows us to provide full name resolution functionality entirely independently of the (badly broken, in security terms) conventional DNS system. These replies happen transparently for anyone on-cstorm.

    Additionally, deepDNS fully implements Dr. Bernstein's DNScurve resolver security framework, itself leveraging c25519 ECC to robustly encrypt and authenticate all upstream DNS query data. This provides strong protections against many forms of cache poisoning and "Kaminsky-style" attacks on DNS query integrity.

    Additionally, we provide native, transparent on-cstorm access to Tor hidden services-based .onion URLs in any browser... as well as full, native, transparent transit of all Tor traffic for on-cstorm members: any Tor resources are visible and addressable to anyone who is on cryptostorm. This provides an interesting and useful additional mechanism to protect against well-known traffic correlation attack models that have allowed for somewhat widespread access to de-anonymisation of Tor network traffic (given certain conditions are met).

    Finally, we provide native, transparent access to .i2p-based websites ("eepsites") via inproxy/outproxy functionality enabled by our deepDNS mesh. Thus, anyone on-cstorm can visit any .i2p URL in-browser with no additional tools, installations, or configuration changes required.

    We are at the moment enabling fully-secured .bit resolver access to pre-session "geoprofile" coordinates for anyone who prefers to use this rather than conventional DNS queries to do their session connection negotiations. This should be published and available to all cryptostorm members by the end of this weekend.

12. Do you have physical control over your VPN servers and network or are they outsourced and hosted by a third party (if so, which ones)? What countries are your servers located?
  • The putative security benefits of "bunker-based" hosting have been widely debunked, and we do not engage in such shenanigans.

    Rather, we deploy nodes in commodity datacentres that are themselves stripped of all customer data and thus disposable in the face of confirmed attacks on their kernel integrity. We have in the past "downed" such nodes based on alert from onboard systems and offsite, independently maintained kernel logs that confirmed a kernel-level violation was taking place. It is important to note that such "downing" does not explicitly require us to even have physical (or root) control of the machine in question: we push nameserver updates, via our HAF (Hostname Assignment Framework) out via redundant, parallel channels to all connected members and by doing so we can "offline" any node on the network within less than 10 minutes of initial commit.

    This represents tangible security benefits for our members, against several known attack models that have been well-documented by security forensics specialists in recent years.

    Our currently-deployed geoclusters are listed in the previous post.

Best regards,

~ cryptostorm
cryptostorm_support shared support team forum account
PLEASE DON'T SEND PRIVATE MESSAGES with support questions!
--> 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! validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email:
live chat support: #cryptostorm

User avatar
Site Admin
Posts: 1275
Joined: Wed Feb 05, 2014 3:47 am

Re: Replies to recent interviews

Post by parityboy » Sat Feb 28, 2015 11:03 pm


Many thanks for posting this. Just out of interest
Indeed, on-cstorm visitors to "DNS leak" websites see a message directly from cryptostorm, embedded in the results presented...
What is this message? I've tested a couple DNS leak test sites while on Cantus, and I've not seen any such message.

User avatar
Posts: 612
Joined: Sun Dec 16, 2012 6:34 am


Post by Pattern_Juggled » Sun Mar 01, 2015 10:01 am

parityboy wrote:
Indeed, on-cstorm visitors to "DNS leak" websites see a message directly from cryptostorm, embedded in the results presented...
What is this message? I've tested a couple DNS leak test sites while on Cantus, and I've not seen any such message.
One needs to dig to get it...

Some additional metrics on deepDNS resolutions, courtesy netalyzr:
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

[list]✨ ✨ ✨[/list]
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github