Thanks a lot for taking the time to read the security model so thoroughly and for providing such a detailed critique. I didn't think someone would do it ! This is extremely valuable feedback.
A few thoughts on your specific points:
- You are right about the web threat model. Serving the crypto bundle over the web means trusting the server not to serve malicious JS at load time. Moving towards reproducible builds, bundle hashing, or a dedicated browser extension is definitely the long-term path to remove operator trust on code delivery.
- For the `auth_salt_${username}` salt, this is a choice I made at the beginning of the project, an error, and it should be replaced soon. However, this is only used for authentication and not encryption.
- Changing the master password does not orphan CryptPad documents. The master password is solely used client-side to derive the wrapping key that encrypts the underlying persistent secrets (the PGP private key and the CryptPad account pass).
When changing the password:
1. The persistent secrets are unwrapped in RAM using the old derived key.
2. They are re-wrapped using the new key derived from the new master password.
3. CryptPad's native account key update process is triggered with old and new secret.
Framing AurionMail as "client-side encryption with a trusted operator" rather than absolute ZK is a fair and accurate classification of the current web-based threat model. I'll update the documentation and security spec to clarify these trust assumptions explicitly.
love the direction have asked myself manytimes why this feature sent doesn't exist somewhere; for sure would need to see some high profile people start using this to think its bullet proof
4 comments
[ 0.21 ms ] story [ 15.2 ms ] threadA few thoughts on your specific points:
- You are right about the web threat model. Serving the crypto bundle over the web means trusting the server not to serve malicious JS at load time. Moving towards reproducible builds, bundle hashing, or a dedicated browser extension is definitely the long-term path to remove operator trust on code delivery.
- For the `auth_salt_${username}` salt, this is a choice I made at the beginning of the project, an error, and it should be replaced soon. However, this is only used for authentication and not encryption.
- Changing the master password does not orphan CryptPad documents. The master password is solely used client-side to derive the wrapping key that encrypts the underlying persistent secrets (the PGP private key and the CryptPad account pass).
When changing the password: 1. The persistent secrets are unwrapped in RAM using the old derived key. 2. They are re-wrapped using the new key derived from the new master password. 3. CryptPad's native account key update process is triggered with old and new secret.
Framing AurionMail as "client-side encryption with a trusted operator" rather than absolute ZK is a fair and accurate classification of the current web-based threat model. I'll update the documentation and security spec to clarify these trust assumptions explicitly.
Thanks again for your feedback !