Enshroud dApp Access

Here at the Enshroud Project, we take seriously our commitment to privacy and strong encryption. This means that we cannot utilize any encryption technology that we have reason to believe may be inadequate or compromised.

Unfortunately this means that we cannot use HTTPS in the context of our dApp. This is not because of any known defects in the SSL/TLS encryption algorithms on which it relies. Rather, it's because the Public Key Infrastructure (PKI) for HTTPS has been compromised by "captive CAs" who supply fake certificates for MITM attacks to LEOs and spy agencies. (If you think this is an exaggerated claim, please read this article. They are now admitting publicly what has long been standard practice.)

At the same time, it's vital that our dApp protect users' communications with our L2 MVO servers using strong encryption. In order to provide this without reliance on HTTPS, we deployed ECIES, a hybrid ECDSA/AES-256 encryption algorithm, to generate one-time keys for every message exchange. This is superior encryption, which travels over ordinary HTTP.

It's also vital that our MVO servers (which are essentially privacy miners) should operate like crypto miners (bare IPs, no domains or site certificates), to reduce the attack surface against their operators. This goal is also accomodated by building on ECIES. (Note the URLs and public ECDSA keys of MVO nodes are recorded on-chain.)

Therefore, the Enshroud dApp is published on IPFS.

You can access our dApp here:
http://localhost:8080/ipns/k2k4r8ontb0dinlp1ifvflzjzt11ngbj2huz9agk4h9v7ztuo2rblsy0

which your browser may rewrite equivalently as:
http://k2k4r8ontb0dinlp1ifvflzjzt11ngbj2huz9agk4h9v7ztuo2rblsy0.ipns.localhost:8080/

Access via IPFS (Interplanetary File System) also has the effect of guaranteeing file integrity, since all addressing is via content hashes. (An HTTPS website cannot do this.) These IPNS (Interplanetary Name Service) links will remain consistent across updates, and assume your local IPFS gateway is running on the default port of :8080.

There is one wrinkle:

Because browsers won't access HTTP URLs from within a "secure" HTTPS context, you cannot use a https:// gateway URL to access our IPFS content. (You might pull up the dApp, but communications to our L2 nodes wouldn't function.) This means that the IPFS Companion and similar plugins won't work, because they rely on public relays secured with HTTPS.

We recommend that you install Kubo, the IPFS Go client. You can obtain Kubo here.  Extensive documentation including installation guidance is also available at that link.