Continuing a discussion at:
Thank you faxe!
Hey @jonah, @dngray! Sorry about the delay, we were waiting for the results from our latest audit.
The audit that Fallible had previously performed was a pen test, while this one (performed by Cure53 and Symbolic Software) is a cryptography review + source code audit, which provides a stronger guarantee of our security and privacy posture.
Please find more details here: ente successfully completes a security audit.
If you have any follow up questions, please let me know.
Thanks!
Yes I have some follow-up questions for you:
Did you ever end up getting a letter of attestation or public report from Fallible, just out of curiosity?
Are you able to determine whether any current users (and/or how many) are affected by ENT-01-001
(i.e. have weak passwords)?
ENT-01-002
is an interesting problem, I think that we would have to include a warning about it on the site because encryption strength is directly tied to password strength, so changing a weak password to a strong password would not increase encryption strength. This is particularly a problem for anyone that might be affected by ENT-01-001
of course. Am I correct in thinking that the only solution in this case would be to create a new ente account and re-upload?
What was Symbolic Softwareâs role in this? Did they have a separate report?
Overall though, I think ente is coming out of this looking quite good! @dngray you have been testing ente and liked it, right? Iâm going to mark this as approved and we can start working on adding it to the site (I am thinking a new photo management providers page), but Iâll also wait for @vishnukvmdâs responses here to determine how exactly weâll word the listing
Hey!
report from Fallible
Requesting an attestation for a stale pentest required us to have lengthy conversations, which we felt was unnecessary since we had the Cure53 audit lined up. So the truth is, we didnât try
That said, we have a good working relationship with Fallible, so if you think an attestation is necessary, we should be able to figure something out.
ENT-01-001
No, we have no information about user passwords.
ENT-01-002
The entropy of your encryption keys is unrelated to the strength of your password.
When the blog post mentioned that âstrength of our encryption depends on your passwordâ, what we meant was that it is easy to brute-force a weak password. You can increase your accountâs security by switching to a stronger password.
More details on how this works is documented here.
Sorry about the confusion, and thanks for pointing this out, we will figure out a way to phrase this better.
Symbolic Softwareâs role
Cure53 had consulted Dr. Nadim Kobeissi, who runs Symbolic Software to lead this audit. The final document was prepared by both parties, and shared with us under the Cure53 banner.
Dr. Nadim has publicly disclosed Symbolic Softwareâs participation here.
No worries, it would just be nice to know what Fallibleâs conclusion was at that time. I did see Dr. Nadimâs tweet, I just wasnât sure if that final document was the result of both partiesâ work because Symbolic/Nadim was not mentioned in the PDF, so thank you for the clarification.
Am I misunderstanding the ENT-01-001
issue? From the audit report:
Passwords are used to derive the root key material for all ente symmetric encryption keys, and thus, their strength is integral to the confidentiality and integrity guarantees provided by the applicationâs end-to-end encryption design.
That sentence is what led me to my assumption. I do think that your architecture page does explain it better, so let me make sure I understand this right:
When you register, the client generates a masterKey
which is not related to the strength of your password. It also generates a keyEncryptionKey
which is related to the strength of your password.
When you change your password, the keyEncryptionKey
is updated (improving the encryption there) but the masterKey
is not updated (this is ENT-01-002
as I understand it). However, because the masterKey
is already strong and unrelated to your password strength, this is not really a big deal.
Does that sound correct?
I still feel like I was right the first time actually, let me explainâŚ
The encryptedMasterKey
is secured with the keyEncryptionKey
.
Thus, if you had a weak password (ENT-01-001
), you could brute force the keyEncryptionKey
to unlock the encryptedMasterKey
and obtain the masterKey
.
If you later change your password from a weak password to a strong password, the old encryptedMasterKey
is not invalidated, because the resulting masterKey
is the same (ENT-01-002
).
Therefore, if an attacker obtained your weak encryptedMasterKey
at some point, your masterKey
could still be vulnerable even after a password change. That attacker could hypothetically be you, maybe you store old encryptedMasterKey
s on your server, or it could be anyone with access to the userâs email account thanks to ENT-01-003
.
Let me know if I am still confused about something. I donât think I see this as a very realistic attack, I just want to make sure I am interpreting Cure53âs report correctly.
Yes, thatâs correct, we only derive the keyEncryptionKey
from the password, and not all keys.
Yes, we also donât see this as a realistic attack.
In a nutshell you could say that if someoneâs encryptedMasterKey
and the corresponding password are both compromised, their current encryption could be vulnerable even after a password change.
Okay, thanks! Sounds good, I just wanted to make sure I had a solid understanding of your architecture.