[eGQjxkKF6fif]

Intel's remote attestation verifies that, with the hash you can use Intel's remote API which is what the client is doing, Intel gets the hash the server sends, verifies it using their encrypted key set and then tells the client that it's valid and verified. Not all processors have SGX capability to verify the hash. Intel provides tools to do the manual verification if you utilize SGX

https://www.intel.com/content/www/us/en/developer/tools/soft...

So you can verify locally and Intel's API also does the verification.

When an SGX Encalve is created, the private key to it goes within it, it can't be accessed. That's the security.

It's a good read if you look in to the tech on Intel's website.

[phillipseamore]

It verifies that something is running in the enclave. Without the source you can't hash it yourself (don't need an SGX capable system for that, just the SDK) to verify that it's the actual code running.

[eGQjxkKF6fif]

it would be verifying that WireGuard (https://www.wireguard.com/repositories/) is within the enclave, yeah?

[phillipseamore]

Have no idea since there isn't any code available for review. Technically what's running in SGX could just be what's enough for it to attest to it's existence [sidenote: how can I be sure this is even the SGX handling my connection and not just any SGX?]. I really like this idea but even if the code was available most users are still just trusting vp.net (won't be doing their own verification [and doing it everytime the hash has changed] but trusting vp.net's own claims in their own client, it's similar to the criticism of many E2EE messaging solutions, everything might be fine over the wire but I'm trusting their client not to collect or transmit anything before encryption or after decryption). If I could build my own client and lock it down to a hash of published SGX code then I'd be happier, or perhaps if an external party would handle the verification. Looking forward to explore this better when any code is made available.