Ξ 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 Ξ

LOCKED: voodoo.network: alpha token batch

To stay ahead of new and evolving threats, cryptostorm has always looked out past standard network security tools. Here, we discuss and fine-tune our work in bringing newly-created capabilities and newly-discovered knowledge to bear as we keep cryptostorm in the forefront of tomorrow's network security landscape.
User avatar

Topic Author
cryptostorm_dev
ForumHelper
Posts: 20
Joined: Wed Jan 23, 2013 5:31 am

LOCKED: voodoo.network: alpha token batch

Postby cryptostorm_dev » Tue Sep 22, 2015 10:43 pm

{direct link: voodoo.network/alpha + cryptostorm.org/voodoo}

NOTE: voodoo functionality is now in process of being universally deployed across the entire cryptostorm network; the official announcement provides details and deployment roadmap. Many, many thanks to the voodoo alpha token holders who helped make this enormously-promising network-wide security upgrade possible! (also: this thread is now locked, and ongoing discussions have shifted over to the new 'BeyondVPN - multi-layer, voodoo topology' thread, here in the forum... thanks)


A few weeks back, we shared (via a post on the cryptohaven blog) a pre-release glimpse of what we were calling at the time "haven tokens." Specifically, this is the section discussing this new thing we'd created...

Today, we're proud to say that we've begun "alpha" testing of this new capability... even though we don't really have a name for it yet ("network.wtf" has been floated by one team member around here... most folks who know us can likely guess who that is, too).

But we know what it does, and that's something close to magical.

All the data coming and going from these new cryptostorm secure sessions will have metadata that don't match up to a full-scale cryptostorm server (a "dedicated node"), but rather look as if they come from a transient, disposable "sub-node" that can be located geographically anywhere in the world. The cryptostorm server still does all the actual cryptographic work - the part that requires heavy security for the computer doing it - but to the outside world, the data come and go from these temporary sub-nodes... and those sub-nodes, in turn, come and go as often was want to create, use, and delete them.

With this new capability, an attacker trying to make sense of what is coming and going from cryptostorm faces a kaleidescope of ever-changing addresses, routes, and servers... none of which are our actual physical servers. It's sort of like we're able to "chaff" our metadata with whatever we want - without doing anything to limit the transit of member traffic along the way.


Shortly thereafter, df published a high-level technical summary in the repository we created to support code and configuration publication. In part, he noted that...

...CS only uses dedicated servers for our exit nodes. The unmetered dedicated servers we prefer can be very expensive in some locations. That's the main reason CS has such few IPs.

A lot of VPN providers will run an OpenVPN server on a VPS because a VPS is dirt cheap compared to a dedicated server. However, it's impossible to secure the OpenVPN process on a VPS since it's just a VM guest, and the server that's the VM host can monitor anything going on in the VM guest (or mount the VPS' hard drive image file somewhere and grab the private OpenVPN keys and use them to decrypt client traffic).

That's the reason CS has never used a VPS for running an OpenVPN server.

With this setup, we can use a VPS as the exiting point for VPN traffic without any of the aforementioned VPS security issues applying.


At around the same time, we settled on "voodoo networking" as a name for this new thing we've created... or just 'voodoo' for short. We think that, as the impact of voodoo networking becomes clear over time it will also become obvious that the term "voodoo" was perfect for this particular networking magic.

voodoo-needles.png



Alpha 'voodoo tokens'

In order to test, refine, and improve the voodoo capability, we decided to release a small batch of tokens for use with the initial voodoo-enabled components of our network. These tokens, to be clear, do not enable access to cryptostorm overall (that's why we've included conventional six-month cstorm tokens in the alpha packages created). Instead, they are tied specifically to the voodoo infrastructure. This allows us maximize what we learn from the test, without setting this strange new capability loose on the entire cryptostorm network until we're fully prepared to do so.

Having made that decision, we went ahead and wippped up a 'buy button' enabling the purchase of alpha voodoo tokens. For $56 (plus, enigmatically, a "shipping charge" of $3.50 that nobody can explain... but seems appropriately mysterious for the voodoo deploy), members receive a dedicated voodoo token for the alpha testing, plus a six-month (conventional) cryptostorm token...

voodoobutton.png


We weren't being intentionally enigmatic; it's just that we weren't sure how to get the ball rolling on the alpha test.

After a week or so of internal discussions and brainstorming, we're good to go.

voodoo-mask.png



Voodoo: The Brass Tacks

When a cryptostorm member initiates a voodoo session with our network, there's no longer a linear path through which each packet comes and goes. Instead, outbound packets take a "detour" to a voodoo node (a VPS instance that can be anywhere in the world), although they remain encrypted during this side trip. When they hit that voodoo node, their header metadata updates: in particular, source IP address for the packet is set as the voodoo node IP address. However, the packets then return to the core node - a full-bore, dedicated cryptostorm server - are, decrypted by openvpn, and transit out onto the internet.

The voodoo is that the packet retains the source IP address of the voodoo node, from that detour it took in mid-session. Normally that source IP would be listed as the exitnode (what we're calling a "core node" here, since exiting becomes a multi-step process in the voodoo model). So, when you visit sites or run an "IP test," they show that voodoo node as your physical IP address.

It's kind of simple, but at the same time totally contrary to many assumptions we all have regarding IP networking. But it works, it's "legit" in terms of internet standards, it's not faking or "spoofing" anything.

For the alpha test, we've set up two resolvers to which alpha token holders will connect:

    windows.voodoo.network
    linux.voodoo.network


Each of these, in turn, we'll be directing at various voodoo topologies: different exitnode/"core node" locations, different voodoo node side-trip detours, etc. That's why we're doing this as an alpha test. Some of this will be a bit "on the fly" and fluid as we make use of the traffic from alpha testers to get a feel for things like bandwidth requirements, performance tuning, latency management, and so on. Nobody's ever done voodoo networking before, so we can't go to the literature to get a feel for any of these questions. We're breaking new ground, and the alpha test helps us do that in a more systematic way.

It's likely we'll spin up additional voodoo resolver mappings during the alpha test, to allow for specific voodoo trajectories through the network. But the main windows/linux resolvers will always point to live voodoo nodes during the alpha test.

There's a few minor tweaks to our version 1.4 configuration files, that are needed to enable voodoo functionality. We've posted the test-phase versions of these configs in the voodoo githhub repository and we'll likely be revising and fine-tuning those as we go, as well.

That's that, in terms of voodoo cstorm connections.


Alpha Voodoos: Gathering & Integrating Feedback

Rather than rushing voodoo into full production and putting on a big marketing push, we've chosen to take a stepwise, test-heavy approach. In addition to what we've said above, we find it absolutely imperative that we have a strong confidence in the security profile of voodoo sessions.

To be clear, in theoretical terms there's nothing here that changes the core cryptographic model of our network. However, lots of things that seem fine in theory break down in reality. Since voodoo truly is new, we're going to make sure we have a good sense of how it plays in security terms, before we put our stamp of confidence on it and make it avaliable to the membership overall.

So let's put this one in bold letters, just to be clear (we don't do this often, but when we do it's for good reasons):

    Voodoo sessions during the alpha testing phase are a work in progress. Do not trust your life or safety to them until we've completed the alpha test and published results. This would be a very reckless thing to do. While we don't expect security issues in voodoo sessions, we're also quite paranoid enough to be cautious until the hard data come back to confirm things are all working as expected. This is an alpha test, not meant for life-and-death network security scenarios.

That should be enough hectoring on the subject of security and alpha test scenarios.

We'll be glad to accept feedback from alpha voodoo testers via any channel that works for them. Perferred, however, is a thread in this subforum (we'll be opening a dedicated alpha test feedback thread shortly) or 'issue' reports posted to the github repository. Anyone who purchases an alpha voodoo is welcome to join the repo and participate in its management; if you've not done that before and would like to learn how, post a reply in this thread and we'll get you connected with someone experienced in github-fu.

Finally, we've created a dedicated email distribution address - alpha@voodoo.network - that sends copies of inbound correspondence to the tech team members working directly on the voodoo project, as well as our support desk. So if you've got questions or an issue or just want to get ahold of someone voodoo-aware on our team, that's the quickest way to do so.

In terms of communications, we'll be posting the usual updates and commentary on the voodoo test in our main @cryptostorm_is feed, of course. However, since that can be a bit heavy in volume and tone for some folks, we're also cross-posting all #voodoonet-tagged tweets to the human-friendly @cryptohaven twitter feed, as well. So if you want to get your voodoo updates with minimal chatter, that's the place to go.


In Conclusion...

In conclusion, we've no doubt that there will be additional issues that we've neglected to add into this tutorial on alpha voodoos. As they arise, we'll edit this first post in the thread, to keep it current. If it's a notable addition, we'll post a reply with details on the edit. And, of course, input and questions and most anything else contributed by the member community is most welcome in this thread.

Voodoo networking is, by definition, a work in process. Rather than pretend otherwise, we've embraced that and are seeking to use that fact to improve and acccelerate the voodoo revolution itself. It'll be a bit chaotic sometimes, and messy in the way all organic things can be messy... but we think that's healthy, especially in a security-focussed context like this.

Kick the tires, test it out, collect data on your voodoo sessions and post them here. Ask questions, challenge our assumptions, suggest ways we can use voodoo to make even more secure network systems in the future. Voodoo isn't "owned" by cryptostorm - we've already published the baseline techniques that make it work, and we'll keep publishing details as they settle into stable form - but rather is a technique that is freely available for use by anyone, in any context. Let's get things rolling on a good foot, so this new tool in counter-surveillance technology has the best start on a revolutionary future.

Oh right, one more thing: how long will the alpha voodoo tokens be valid for, and how long will the alpha test run? We don't know test duration in advance, because testing is always an emergent process. In general terms, we expect to spend a month or so in alpha phase, before rolling forward to a much more broadly available beta test. The beta test will likely run until the new 'Black Dolphin' widget version releases, at which point voodoo functionality will be seamlessly integrated into the cryptostorm network overall. That's an early/mid-fall target, for the release of Black Dolphin.

Folks who purchase alpha voodoo tokens will also, of course, have full access to beta voodoo functionality. Once voodoo is fully integrated into the new widget release, and is no longer a standalone/separate sub-network within cryptostorm, we'll be spinning down the separate voodoo tokens entirely.

When we do that, we'll provide to our alpha voodoo testers newly-issued "tokens(2)" ECC-based, c-25519 keypairs of duration 169 days. Because, yes, we are deploying a completely revised and upgraded, cryptographically enhanced token model as part of the Black Dolplin deployment this fall. We've putting details on tokens(2) in a separate thread, here... but if you've wondered why voodoo tokens are a bit weird compared to "normal" tokens, that's why: they're a first iterations of tokens(2).


Derp, almost forgot: YourNickHere@voodoo.network

Everyone who picks up an alpha voodoo token gets a {whateveryouwant}@voodoo.network email account... that is soon to transition to an SMTP/POP#/bitmessage gateway via our bitmessag.es comms gateway. Which might come in handy for this and that... who knows?

Tally ho,

~ cryptostorm

voodoo-datacenter.png

User avatar

Graze
Posts: 247
Joined: Mon Dec 17, 2012 2:37 am
Contact:

Re: voodoo.network: alpha token batch, official release

Postby Graze » Tue Sep 22, 2015 11:22 pm

cryptostorm_dev wrote:For $56 (plus, enigmatically, a "shipping charge" of $3.50 that nobody can explain... but seems appropriately mysterious for the voodoo deploy)...



hqdefault.jpg
------------------------
My avatar is pretty much what I look like. ;) <-- ...actually true, says pj
WebMonkey, Foilhat, cstorm evangelnomitron.
Twitter: @grazestorm.
For any time sensitive help requests, best to email the fine bots in support@cryptostorm.is or via Bitmessage at BM-NBjJaLNBwWiwZeQF5BMLYqarawbgycwJ ;)

User avatar

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

Re: voodoo.network: alpha token batch, official release

Postby marzametal » Wed Sep 23, 2015 6:21 am

this is the game changer, isn't it...

User avatar

klepto
Posts: 4
Joined: Thu May 14, 2015 11:41 am

Re: voodoo.network: alpha token batch, official release

Postby klepto » Wed Sep 23, 2015 9:38 am

I'm in! This is right up my alley as a paranoid netsec dude. I like the name, as voodoo implies there's some spooky magic involved. I've coughed up my beer/gun range funds. Cryptostorm is planning for the future, and making it difficult for the alphabet boys.

User avatar

KonamiCodeNeeded
Posts: 21
Joined: Sun Aug 30, 2015 1:04 am
Contact:

Re: voodoo.network: alpha token batch, official release

Postby KonamiCodeNeeded » Wed Sep 23, 2015 11:51 am

What is the voodoo.network? Why is it worth the money? just inquiring.


dccc
Posts: 24
Joined: Mon Jan 12, 2015 10:57 pm

Re: voodoo.network: alpha token batch, official release

Postby dccc » Wed Sep 23, 2015 9:32 pm

What about the Aleph token folks? Do we get a new Aleph token, once the Voodoo testing is completed? Thanks for your work, I'm looking forward to your findings :-)


mart-e
Posts: 16
Joined: Thu Jul 02, 2015 5:07 pm

Re: voodoo.network: alpha token batch, official release

Postby mart-e » Thu Sep 24, 2015 12:45 am

Looks worth a try but... Paypal only, no Bitcoin payment ? :?


anony001

Re: voodoo.network: alpha token batch, official release

Postby anony001 » Sat Sep 26, 2015 11:43 pm

I am interested in purchasing a few haven voodoo tokens for testing in our organization - we can only pay using bitcoin. Please advise how to proceed.


anony

Re: voodoo.network: alpha token batch, official release

Postby anony » Sun Sep 27, 2015 12:42 am

So, what keeps a compromised voodoo node from blocking plaintext streams from the internet, and then watching for the related encrypted stream to dry up?

I don't think this is fail-safe for the user the way it's currently set up.

I don't imagine user experience being much if any worse. Proximate geolocation of nodes to cores can minimise the requisite latency penalty, and over-provisioning can likely improve overall node throughput.

It will have a significantly reduced 'per-server' bandwidth capacity and client pool size, thusly traffic flow entropy though -due to all the redundant traffic. I'm not sure how much a factor the client pool size is?

From what I understand, it would be hard to understate the value of scale/capacity/flexibility that VPS's can potentially add to the network, it's awesome this is being explored; it may be a difficult thing to get right though.

iirc DF stated that a dual voodoo node (ingress/egress) is the endgame goal for this on github, but there's no config for that yet... How would the forwarded IP's be handled in such a case? I can imagine that meeting fail-safe status for both CS and member, though I'm not exactly sure how.


Serbia

Re: voodoo.network: alpha token batch, official release

Postby Serbia » Mon Sep 28, 2015 9:41 am

TCP is slow as balls. You guys probably already know but just as an Ubuntu user. Completely aware this is alpha though. Excited to see how the final version comes out! :)


anony

Re: voodoo.network: alpha token batch, official release

Postby anony » Wed Sep 30, 2015 2:36 am

Bump.
It's been a couple days; I know you guys are busy with full spectrum cyber security stuffs ;) . A response would be nice when you have a moment.


TCP is slow as balls. You guys probably already know but just as an Ubuntu user. Completely aware this is alpha though. Excited to see how the final version comes out! :)


If you read the github you'll see that it's either tcp or udp- check your config.


hello1

Re: voodoo.network: alpha token batch, official release

Postby hello1 » Wed Oct 07, 2015 6:25 am

Would love to try but have to pay in BTC. Hope we can work something out

User avatar

parityboy
ForumHelper
Posts: 860
Joined: Wed Feb 05, 2014 3:47 am

Re: voodoo.network: alpha token batch, official release

Postby parityboy » Wed Oct 07, 2015 10:28 pm

@df

Yeah it sounds like a form of SNAT spoofing. :) What's the performance been like, in terms of latency? How does it compare to using Tor, in those terms?

User avatar

df
Site Admin
Posts: 226
Joined: Thu Jan 01, 1970 5:00 am

Re: voodoo.network: alpha token batch, official release

Postby df » Wed Oct 07, 2015 11:25 pm

The speeds are pretty awful at the moment, maybe even worse than tor. But I suspect that's mainly to do with the horrible speeds of the two test VPSes in Indonesia and Serbia and their distance (and lack of relation in uplinks/IXs to the core). Also because we haven't done much perf tuning yet at the cores specific to voodoo. The post-test phase will most likely be done with a .nl core server at someplace like Leaseweb (who can provide good speeds), along with some perf tuning and a /24 or so that can be setup where every 2 IPs goto a different exit/voodoo node. That plus VPSes at much faster places than the two hosters we're currently using, maybe at ISPs that are geographically closer to the core or at least share an IX/gateway/uplink. That should make speeds much faster than they are now. But even then, nobody should be using this if they're just torrenting. Direct connect to the core node is more than enough security/anonymity for stuff like that. Voodoo is more for people doing plain ol browsing/emails and need a little bit of extra layer thrown in to make correlation attacks insanely difficult. Also jump nodes would help with that, once we put those into place :-)

User avatar

parityboy
ForumHelper
Posts: 860
Joined: Wed Feb 05, 2014 3:47 am

Re: voodoo.network: alpha token batch, official release

Postby parityboy » Thu Oct 08, 2015 10:49 pm

@df

Did you ever consider using existing Tor exit nodes as voodoo nodes? Don't worry, this idea literally just came to me, so I did some DDG and found tortunnel.

Worth a look, or did you already rule it out?

User avatar

df
Site Admin
Posts: 226
Joined: Thu Jan 01, 1970 5:00 am

Re: voodoo.network: alpha token batch, official release

Postby df » Fri Oct 09, 2015 5:03 am

Not really, as it's easier for someone to just hop on tor after connecting to CS, if they want to. Also tor's way too slow. The production level voodoo nodes will be much faster than they currently are, so speeds will be better than tor :-)

User avatar

parityboy
ForumHelper
Posts: 860
Joined: Wed Feb 05, 2014 3:47 am

Re: voodoo.network: alpha token batch, official release

Postby parityboy » Sat Oct 10, 2015 6:26 am

@df

I just suggested it simply because the Tor exit nodes are already there so they are basically free of charge to use, and it would be a single hop from the core node to the Tor exit node. True enough though, the throughput of a given node would be...unpredictable...at best - you'd likely have to create and actively maintain a list of the fastest exit nodes available. Having said that though, as you pointed out earlier, the voodoo architecture is for people using plain old email & web browsing, so I imagine latency would be a bigger issue than throughput.

[I may build a working prototype, just for fun...]

By the way, with regard to the voodoo VPSes, do you have any requirements as to what the underlying virtualisation technology should be, i.e. KVM vs Xen vs containers? I ask because obviously for a VPS you would have no say in how the host kernel and networking stack are tuned.

User avatar

df
Site Admin
Posts: 226
Joined: Thu Jan 01, 1970 5:00 am

Re: voodoo.network: alpha token batch, official release

Postby df » Sat Oct 10, 2015 9:04 am

As far as I can tell, the exit VPS needs to be KVM because it requires the ip_gre kernel module. With OpenVZ (probably Xen too, haven't tested) you would need to be able to install the kernel module and setup the GRE tunnel interface on the host (or whatever it's called), which is not likely to happen with most VPS providers.

User avatar

parityboy
ForumHelper
Posts: 860
Joined: Wed Feb 05, 2014 3:47 am

Re: voodoo.network: alpha token batch, official release

Postby parityboy » Sat Oct 10, 2015 4:19 pm

@df

I think Xen is similar to KVM in those terms, from everything I've read - it's a Type 1 hypervisor. In fact if you think back to when CS was considering using Xen for core instances, each Xen guest would have been running its own kernel, and therefore it's own copy of the tun kernel module.

User avatar

df
Site Admin
Posts: 226
Joined: Thu Jan 01, 1970 5:00 am

Re: voodoo.network: alpha token batch, official release

Postby df » Sat Oct 17, 2015 5:42 am

heh, I've got a hyperv (that's M$) one in Saudi Arabia now. It's @ 5.154.191.28 win, 5.154.191.29 raw if anyone is bored. Just keep in mind that this is a Saudi Arabia exit node, so stuff like porn sites etc. are blocked by the internet.gov.sa entity. I got it mainly just to see how easy it was to bypass internet.gov.sa's blocks. Turns out it's fairly easy thanks to deepdns' transparent .onion access. I.e., the simple PHP based web proxy thing I just setup @ http://xorppza6re4tu3jt.onion/ can be used to bypass the internet.gov.sa blocks.

The other, less ridiculous node is @ 5.154.191.26 (win) & 5.154.191.27 (nix), that one exits in Iceland.

User avatar

vpnDarknet
Posts: 129
Joined: Thu Feb 27, 2014 2:42 pm
Contact:

Re: voodoo.network: alpha token batch, official release

Postby vpnDarknet » Sat Oct 17, 2015 2:50 pm

Nice work, I'm voodoo surfing via iceland, but no luck connecting to the raw Saudi node, sure it's a problem I can solve at my end Insha'Allah
Buy your tokens via vpnDark.net and cryptostorm cannot and does not know anything about users - no link between a token & purchase details
Unofficial Wiki cryptostorm access guide
Ways to talk to me

User avatar

df
Site Admin
Posts: 226
Joined: Thu Jan 01, 1970 5:00 am

Re: voodoo.network: alpha token batch, official release

Postby df » Sun Oct 25, 2015 1:23 am

The win .sa IP seems functional to me, but the linux one is acting up.
Locally (on the VPS), I can reach the internet using the linux instance IP, but the internet can't reach it unless the connection was related to the outgoing reqeuest.
Almost as if .gov.sa or the .sa VPS provider did:

iptables -A INPUT -d 5.154.191.29 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -d 5.154.191.29 -j REJECT

That or I screwed up somewhere in the setup, but I dun think that's it cause I cleared all the voodoo stuff on the VPS and still saw the same behavior.

Oh well, win still works, and this exit wasn't really intended for anyone to use for anything other than testing.

User avatar

df
Site Admin
Posts: 226
Joined: Thu Jan 01, 1970 5:00 am

Re: voodoo.network: alpha token batch, official release

Postby df » Mon Nov 23, 2015 11:55 pm

DudeOfLondon: At the moment the exit IP isn't chosen randomly. The current server list is @ https://github.com/cryptostorm/voodoo.network


DudeOfLondon
Posts: 105
Joined: Sat Jan 10, 2015 5:14 pm

Re: voodoo.network: alpha token batch, official release

Postby DudeOfLondon » Tue Nov 24, 2015 12:31 am

What a ingenious concept.
I read through the whole readme.
I especially like the last 2 paragraphs (core servers are sage, only VPS are under attack. And geo-ip stuff)

User avatar

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

Re: voodoo.network: alpha token batch, official release

Postby marzametal » Tue Nov 24, 2015 6:02 am

Can't wait till this is rolled out into the storm for all...

User avatar

privangle
Posts: 83
Joined: Thu Apr 25, 2013 5:57 am

Re: voodoo.network: alpha token batch, official release

Postby privangle » Fri Feb 05, 2016 9:51 am

Hi,

I read all the contributions in this thread, it seems to be very interesting, but technically I understood almost nothing, the subject is too difficult for me.

Could somebody try to explain me in a simple way what the subject is about, a sort of "voodoo for dummies"?

Is the goal to hide some metadata which appear in our "simple" cryptostorm connections?

Do you know some introduction article which could help me to understand the subject?

Thank you.

P.S. Is an alpha token another token than the alpha token we could buy one year ago? I bought an alhpa token (in the sense of "lifetime token") - has this something to do with an alpha token we are diskussing here??
Sorry, but its confusing for me. :oops:

User avatar

privangle
Posts: 83
Joined: Thu Apr 25, 2013 5:57 am

Re: voodoo.network: alpha token batch, official release

Postby privangle » Fri Feb 05, 2016 2:13 pm

@df
Thank you for your answer! With your post I'ill retry to understand the thing. At least I understand now what we are talking about.

Your explanation makes me think of the Tor relay chains, my impression is that there are similarities.

So it's about increasing security, preventing or making more difficult the traceability (for attackers).

I didn't know that VPNs can be attacked. I thought the only weak point was logging - certainly a naive view from my side. So it seems that almost everything can be attacked...

Is voodoo something that the CS-team invented, or is it a well known technique in networking?

In any case thank you for your constant effort to increase our security.

User avatar

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

Re: voodoo.network: alpha token batch, official release

Postby marzametal » Sat Feb 06, 2016 3:45 am

Pants.


Last bumped by Anonymous on Sat Feb 06, 2016 3:45 am.


Return to “cryptostorm reborn: voodoo networking, stormtokens, PostVPN exotic netsecurity”

Who is online

Users browsing this forum: No registered users and 1 guest

Login