If you have any questions , comments, or concerns, use any of the contact options provided by the author below.
Adison Verlice
Email:
PGP encryption key:
https://blindsoft.net/publickey.asc
Discord:
@ncladisonverlice
Mastodon:
@adisonverlice@tweesecake.social
verified privacy is a VPN provider that claims to provide privacy in a unique way, which we’ll get into.
What it claims to do is use the intel SGX hardware, providing hardware based privacy.
Don’t worry, we will examine this in a bit, but I would like to start with some of the reasons it is not private.
Javascript has its own privacy drawbacks. It can do a lot of fingerprinting.
For example, if we look at cover your tracks (EFF), we’ll see that browser fingerprinting can be part of javascript. Browser fingerprinting is telling which browser you use, EG, brave, firefox, google chrome.
But that’s not all the problems of javascript. There are even some security problems.
For instance, this article written by Adam Barth, explores exploits in javascript in implementations such as apples webkit used by safari in apple devices.
While we are looking at privacy, not exactly exploitation, it was worth mentioning.
But let’s press on…
If the VPN is supposed to be private, why is KYC required?
In fact, why is it even there?
Even if you do use amazon or google wallet, that is still kyc. Yes, vp only has a token and will be linked to your google account, so on one hand , you have a level of security by not giving vp.net your credit card.
But that doesn’t matter
Google still does its own kyc, so does amazon, so you are just trusting another provider with your data.
And, of course, add on to the fact each payment option requires personally identifiable information (pii) which means if they get breached, either way, your data is at risk.
As a good friend of mine, kevin karhan, once said, “KYC is the elicit activity”.
Did I mention that vp.net doesn’t have an onion service yet?
O, i didn’t? Well, I'm mentioning it now.
That’s right!
Verified privacy does not have any onion service.
That means that they want your actual IP address.
The same goes for the client. The client has your actual IP address, if you are not protected via tor on the network level.
The client needs your information either way, so your login information/username.
This completely defeats the anonymous gig, as the client requires your username, which can still be correlated back to you. If the NSA< CIA< FBI, or any agency, were to subpoena VP, or even their third parties (they do) then that means your data is now in the hands of someone else you didn’t even give permission to.
And this is where we get to the main claim…
This is a complete scam.
First off, if you are in IT and you’ve set up a VPN server before, you will know that the server generates the keys from a protocol, like wireguard or IPSec.
The key is generated on the server, not the client.
This is the first component we will discuss.
The keys are required for encryption.
The key encrypts and decrypts traffic.
The administrators of VP have access to the servers.
If they wanted to, they could go to their log viewer, which is on pretty much any VPN server, and can view the logs solely based on the key for that user.
It can include timestamps, the URL, and the user. If VP installs a rogue SSL certificate for decryption, it can also decrypt the contents, though I have no proof this is the case.
Still, this is false. They can absolutely log based on the key.
The second part of the claim is that intel SGX protects you from this logging by putting it into separate spaces.
Right off the bat, there is a problem here.
In case you don’t know what a trusted execution environment is, it is an environment where applications can securely execute inside of a different operating system, not the client OS.
In intels case, TEE is Intel trusted domain extensions which is part of intel software guard extension environments.
If you’re using Android, another example of TEE is the trusty tee which is open source.
That brings me to my next problem.
The TDX and SGX are proprietary black boxes.
This means that SGX is no more trustworthy than windows, as both are proprietary.
That trust only degrades if you add in the intelmanagement engine which in the past, was enabled by default, and if i remember correctly, still is today.
This means that if the NSA exploits IME, or your adversary exploits it, that means they get access to your entire OS.
But there is also another factor: intel SGX has its own set of vulnerabilities.
Take CVE-2025-32086 as an example
“Improperly implemented security check for standard in the DDRIO configuration for some Intel(R) Xeon(R) 6 Processors when using Intel(R) SGX or Intel(R) TDX may allow a privileged user to potentially enable escalation of privilege via local access.“
This is bad.
And with the TEE being proprietary, it’s not like an open source repository, where someone can easily push a request for a fix, and intel can implement it.
The SGX factor only secures the client from logs, meaning if the client gets leaked, the VPN logs won’t be available in the client.
To VPs credit, they have published the source code for the TDX enclave.
But even then, SGX and TDX are both proprietary. You cannot trust what is running on SGX and TDX themselves.
And, as stated before, it only protects the client/host operating system.
The server could still see what you’re doing
For there to be a, true, no logging policy, first off, the VPN needs to be on an onion service.
Furthermore, monero XMR should be the only thing accepted for currency.
As for key generating, key generation needs to be on the client only. No server clients, there needs to be only client side key generation.
That key needs to stay on the client, with the server not having any power over the key.
Alternatively, there could be a public private key pair, where the server has the public key, and the private key would only be on the client.
If we need a secure element to store the key which is fair, it could be that, for example, trusty on android could provide a confidential computing source for the key, or a secure element, such as the titan M on google pixel devices.
An even better solution would be to store it on a hardware based key such as nitrokey.
A nitrokey HSM would do very well for this purpose. And if you want to do ephemeral key generation using it, you could always utilize the PKCS11 libraries, which should, if done correctly, provide the means to do perfect forward secrecy (PFS).
Because there is nothing to decrypt on the server end, it would protect user internet privacy.
Added to the tor component, it will have 2layers of protection, 1 with tor on the network level, and another on the VPN.
And provided you do XMR, this means that the user will be anonymous.
This is a true hardware backed no logging environment.
Mullvad is a VPN service as well. Except, it has actual privacy.
For example, it has an onion service (requires tor to access) and it allows you to use crypto, like XMR, to purchase mullvad. Furthermore, no KYC, it only uses an account number to verify you.
The client sees your IP, but then again, this can be mitigated with tor either at proxy or at the network level.
I don’t see VP doing this at all.
Mullvad is actually taking steps for privacy.
To be frank, I do not recommend mullvad.
But if I had to go with a VPN solution, this is the one I'd go with.
VP is a total sham, and not worth it at all.