[GH-ISSUE #185] Ms Paranoia tries to ensure Cypht server trustworthiness #153

New issue

Open

opened 2026-02-25 21:34:18 +03:00 by kerem · 3 comments

kerem commented

2026-02-25 21:34:18 +03:00

Owner

Originally created by @dumblob on GitHub (Apr 7, 2017).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/185

Originally assigned to: @jasonmunro on GitHub.

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.

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).
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.

Originally created by @dumblob on GitHub (Apr 7, 2017). Original GitHub issue: https://github.com/cypht-org/cypht/issues/185 Originally assigned to: @jasonmunro on GitHub. 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`). 1. 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](https://en.wikipedia.org/wiki/Homomorphic_encryption#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.

kerem added the

enhancement

research

labels

2026-02-25 21:34:18 +03:00

kerem commented

2026-02-25 21:34:18 +03:00

Author

Owner

@jasonmunro commented on GitHub (Sep 25, 2018):

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

@jasonmunro commented on GitHub (Sep 25, 2018): 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

kerem commented

2026-02-25 21:34:18 +03:00

Author

Owner

@dumblob commented on GitHub (Sep 25, 2018):

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

@dumblob commented on GitHub (Sep 25, 2018): Great news, thanks for that! I alone didn't notice subresource integrity was implemented.

kerem commented

2026-02-25 21:34:18 +03:00

Author

Owner

@jasonmunro commented on GitHub (Sep 25, 2018):

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.

@jasonmunro commented on GitHub (Sep 25, 2018): 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.

kerem referenced this issue

2026-02-25 21:36:10 +03:00

[PR #153] [MERGED] Complete french translation #769