Ente (Photo Management)

Continuing a discussion at:

Right now I believe we are waiting on a report from vishnukvmd:

1 Like

there is an update on the audit situation: ente successfully completes a security audit

3 Likes

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! :slight_smile:

4 Likes

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 :slight_smile:

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 :slight_smile:
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.

2 Likes

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?

1 Like

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

1 Like

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.

1 Like

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.