Ms Paranoia tries to ensure Cypht server trustworthiness

[dumblob]

Currently if you deploy Cypht on anything which is not completely virtualized by you (e.g. through QEMU) or a completely open-source HW of yours, you're risking, that e.g. some cryptography stuff will be compromised (it can be in HW like CPUs, AES chips, network controllers, etc. or in SW like virtual machine, OS kernel, crypto libraries, PHP, altered Cypht code by a third party like the admin on the server, etc.). I believe, we can though improve the trustworthiness (correctness) of Cypht operations in all these cases.

I've thought about this already many times quite thoroughly, but always did come up with just half-way solutions. The following one should work though acceptably well.

1. Definition of the problem: We have 3 nodes: an IMAP server IS, a Cypht Server CS, and the client browser CB. The nodes can communicate only using the following paths: IS <-> CS and CS <-> CB (note, IS <-> CB is not possible). We need to ensure, that CS, acting in fact as a "better" relay, can't under any circumstances do anything else than CB wants. We also do not trust CS at all and thus want the CB approve each logical message (a logical message which might be a bounded set of messages realizing one operation initiated by the user) before sending it to IS. We also want CB to check for trustworthiness/correctness of each logical message received from CS in case its construction involved any newly acquired information from IS (e.g. a list of emails in INBOX received every 5 minutes from IS and "relayed" by CS to CB).
2. Possible solution: Use a similar scheme to Diffie-Hellman or to other key-exchange mechanisms, but adjusted to an infinite number of messages transferred (OTR?). This requires a "completely" trustworthy piece of Javascript on CB. This JS code shall be really minimal (few hundreds of lines at maximum), available from a different source than from the deployed Cypht and will have a very low frequency of updates (to make it viable to manually check each release of it) with each release being cryptographically signed and if possible audited. Note, in the future, once the Fully homomorphic encryption gets usable (mainly in terms of performance), we can even completely guarantee the computation performed by the Cypht server wasn't tampered.

This is still an idea and I'll think about it more and contact few persons from universities about this. I just wanted to make a public note about it. Feel free to comment.

[jasonmunro]

While not directly related to what you are proposing here, we did recently implement sub-resource integrity for the site.js and site.css includes, which I think tangentially related :)

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

[dumblob]

Great news, thanks for that! I alone didn't notice subresource integrity was implemented.

[jasonmunro]

For now I am generating the hash values during the config_gen.php process for the site.php and site.css files, but I need to build the right values for the other potential includes (theme css, HTML compose, encryption lib, etc), but those are static extra includes so I should be able to hard code those. I plan on doing so before the next release.