In an older version packets were sent back in sequence to their original connection to the host, as it was faster.

We since then implemented a system where nproc (16+) buffers receiving packets running at differed intervals, meaning that while packets are processed "in order" the fact this runs in multiple threads, reading packets even from the same client will cause these to be put in queues that will be flushed at different timings.

We have performed many tests and implementing a more straightforward randomized queue (by allocating memory, handling array of pointers of buffers, shuffling these, and sending these shuffled) did not make much of a difference in terms of randomization but resulted a huge loss in performance due to the limitations of the SGX environment.

As we implement other trusted environments (TEE) we will be implementing other strategies and obfuscation methods.

I left the company on principle by relinquishing my shares at a mere fraction (about 1/3) the value. I walked away from millions of dollars, and I am happy with my decision.

Given what happened, we built VP so that trust is no longer required.

That's a pretty big trust already. Intel has much to loose and would have no problem covering up bugs for government in SGX or certifying government-malware.

And intel had a LOT of successfull attacks and even with their cpu they are known to prefer speed than security.

The final signature comes in the form of a x509 cerificate signed with ECDSA.

What's more important to me is that SGX still has a lot of security researchers attempting (and currently failing) to break it further.

Because of the cryptographic verifications, the communication cannot be spoofed.

That's not what your link says, and as far as I'm aware it's not true. Buying crypto and then using some of it to buy goods and services has no tax reporting requirement, those only start when you're either selling crypto or receiving it as payment. Which is the same situation as the tax reporting for any other currency or valuable item you could deal in.

> we operate proudly in the united states. protected by the constitution — not offshore shell games.

> no backdoors. no stored data. even if they ask, we've got nothing.

> we don't dodge the law — we built tech that doesn't need to.

https://vp.net/l/en-US/about

Ultimately, the people who invested their labor into the network felt like they had little control over the future of the project and felt like they had been rug pulled by christel so they left. They did not believe that it was christel's to sell. Ultimately, as soon as the original operators left, the new management have not necessarily left a great impression. For a while, freenode.net would just redirect to a subreddit? And then later it was a reddit clone of sorts? (https://web.archive.org/web/20220505184527/https://freenode....). Channels were taken over at will. There were somewhat dubious partnerships made, crypto products endorsed. The first blog posts made by the new management straight after the changeover were markedly different from the previous messaging - (https://web.archive.org/web/20210730233709/https://freenode....). The original freenode was doing its best to be a place where like minded people could collaborate and communicate without adding too much of a political sway or coloring anything, the freenode after the takeover did not aspire to do any such thing. If in May of 2021 one could've argued that the old staff were a tad too eager to leave, then the newcomers did everything in their power to prove them right in less than a month.

Please do fund FOSS stuff, it really helps. Just don't expect to buy yourself out of being cringeworthy.

I don't have any particular insight here, but isn't that why Five Eyes is used, a workaround for what would otherwise be illegal activities. Not that the current USA regime care about the law, of course.

The GP mentioned Snowden and yet you say this. What material and significant changes have happened since 2013 to make this claim?

I pay approximately 50¢/month for such a setup, and you can probably do it for free forever if you decide to be slightly abusive about it. However, be aware that you don’t really gain any real privacy since you’re effectively just changing your IP address; a real VPN provides privacy by mixing your traffic with that of a bunch of other clients.

Some services will also block cloud ranges to prevent e.g. geoblock evasion, although you’ll see a lot less blocking compared to a real VPN service or Tor.

What would prevent you (or someone who has gained access to your infrastructure) from routing each connection to a unique instance of the server software and tracking what traffic goes in/out of each instance?

A packet goes in to your server and a packet goes out of your server: the code managing the enclave can just track this (and someone not even on the same server can figure this out almost perfectly just by timing analysis). What are you, thereby, actually mixing up in the middle?

You can add some kind of probably-small (as otherwise TCP will start to collapse) delay, but that doesn't really help as people are sending a lot of packets from their one source to the same destination, so the delay you add is going to be over some distribution that I can statistics out.

You can add a ton of cover traffic to the server, but each interesting output packet is still going to be able to be correlated with one input packet, and the extra input packets aren't really going to change that. I'd want to see lots of statistics showing you actually obfuscated something real.

The only thing you can trivially do is prove that you don't know which valid paying user is sending you the packets (which is also something that one could think might be of value even if you did have a separate copy of the server running for every user that connected, as it hides something from you)...

...but, SGX is, frankly, a dumb way to do that, as we have ways to do that that are actually cryptographically secure -- aka, blinded tokens (the mechanism used in Privacy Pass for IP reputation and Brave for its ad rewards) -- instead of relying on SGX (which not only is, at best, something we have to trust Intel on, but something which is routinely broken).

You still have to trust them, you're not wrong but at some point I'll fall back to the common question security people(not me) tell paranoid doubters: Whats your threat model?

If you're running a global child-abusing ring through Mullvad or OVPN(offers static IPv4 for inbound traffic) I don't know what they'd do but they've proved themselves over and over to be organisations you can trust.

OVPN turns around about 1.2M$ with 0.8M$ profit (0), Mullvad turns around significantly more money but with less profit margin (1) (probably funneling profits to a tax haven) so the risk of someone buying out OVPN is there, but "you" are probably not worth it if the ones targeting TPB didn't figure out how to get through.

You can still run TOR over their VPNs as another layer if you're uncertain their reputation is trustworthy enough for your usecase but don't want TOR traffic originating from your IP.

https://claude.ai/share/a47c19f7-8782-4a9f-ae26-2d2adb52eaed

0: https://www.allabolag.se/foretag/ovpn-integritet-ab/-/konsul... 1: https://www.allabolag.se/foretag/mullvad-vpn-ab/g%C3%B6tebor...

You can look up any Swedish company through sites like allabolag or merinfo if you're curious... until they grow into tax-evading evil megacorps :)

Notably: the only part of your system which can be verified is the SGX box, which can only handle encryption. How can we be certain that you are not able to correlate traffic? It is not enough to simply say that you implemented traffic mixing, as that can be defeated by placing each user on their own SGX instance.

lol

SGX has been broken time and again

SGX has 0-day exploits live in the wild as we speak

so... valiant attempt in terms of your product... but utterly unsuitable foundation

The way this works is the enclave on launch generates a ECDSA key (which only exists inside the enclave and is never stored or transmitted outside). It then passes it to SGX for attestation. SGX generates a payload (the attestation) which itself contains the enclave measured hash (MRENCLAVE) and other details about the CPU (microcode, BIOS, etc). The whole thing has a signature and a stamped certificate that is issued by Intel to the CPU (the CPU and Intel have an exchange at system startup and from times to times where Intel verifies the CPU security, ensures everything is up to date and gives the CPU a certificate).

Upon connection we extract the attestation from the TLS certificate and verify it (does MRENCLAVE match, is it signed by intel, is the certificate expired, etc) and also of course verify the TLS certificate itself matches the attested public key.

Unless TLS itself is broken or someone manages to exfiltrate the private key from the enclave (which should be impossible unless SGX is broken, but then Intel is supposed to not certify the CPU anymore) the connection is guaranteed to be with a host running the software in question.