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 vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html .
# 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: cryptostorm.ch/viewtopic.php?f=37&p=5156#p5156 .
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 - cryptostorm.is/uptime - 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
US-West
US-Central
Lisbon (Portugal)
London (England)
Frankfurt (Germany)
Paris (France)
Reyjavik (Iceland)
Moscow (Russia)
Singapore (Singapore)
- Canada-East
What kinds of logs do you keep on users and their activity? How long are these logs stored in your system?
- None. Details: logs.cryptostorm.ch
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?
- Like this.
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.
