Hacker News new | past | comments | ask | show | jobs | submit login

We had started off with AES, and the performance was abysmal on low-end mobie devices and certain web browsers. XChaCha20 in comparison added negligible latency and seemed less prone to human errors.

These weren't the sole reason however. There's a lot of literature on the security aspects of XChaCha20, some of which I'll link below:

- https://soatok.blog/2020/07/12/comparison-of-symmetric-encry... (in our case your masterKey is used to sign all your fileKeys)

- https://crypto.stackexchange.com/a/34458

- https://nordpass.com/features/xchacha20-encryption/#why%20No...

- https://blog.cloudflare.com/do-the-chacha-better-mobile-perf...




Have you correctly evaluated your threat scenarios?

ChaCha is streaming cipher, which is meant to be used on transmission phase, not on data-on-rest(DARE). That is significant difference. In this case, you are implementing Photo storage service, where data is laying mostly on your servers, and not disappearing after the transmission. What is the threat model?

In general, streaming ciphers are considered as weaker alternatives for DARE ciphers. The main risk lies on nonce. In service like this, you are using long-term key. xChaCha provides 192-bit nonce. How likely you are generating identical nonces?

Well. In this case, it might be that this streaming cipher is safe. 192-bit nonce is quite big number.

For example AES-GCM with 96-bit nonce has max message amount of 2^32 when used deterministically [1]

In theory, the AES alternative is much weaker than your current implementation.

[1]: https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=51288...


From the literature we have read, XChaCha20 coupled with Poly1305 is safe for DARE, ChaCha20 in isolation isn't. We're employing the former.


That is what I was saying. Just reasoning just in case, because it was not written. Threat models are the most important aspects in cryptography and you could include them to support you decisions.


We have outlined this within our architecture[1], but I left out Poly1305 in my previous comment in the context of the original question comparing XChaCha20 with AES256.

The devil truly is in the details. :)

[1]: https://ente.io/architecture#implementation-details


I did read that, but I meant that you should describe threat models, and from that point describe implementation how it relates to threats. So describing pure implementation leaves still many questions, and is less convincing. Threat models helps for question "why". Why this is selected? It gives feeling that you have thoroughly gone through the selection process. In cryptography, there are so many different algorithms and they are meant for different uses. There is no one good for everything. It is important to note, that why this is good for this scenario. And what are pros and cons.

If you have correctly described your threat model, it is easier to convince others, that your algorithm selection is good, even if it might have been good already. It leaves so many mistakes out. And from that point of view, it is also easier to sell, especially as you are branding as E2EE service.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: