Earlier quoted context omitted.
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…
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 alt…
Show HN: We built an end-to-end encrypted alternative to Google Photos
371–380 of 421 posts
Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#372Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#373Earlier quoted context omitted.
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 alt…
From the literature we have read, XChaCha20 coupled with Poly1305 is safe for DARE, ChaCha20 in isolation isn't. We're employing the former.
Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#374Earlier quoted context omitted.
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.
The devil truly is in the details. :)
Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#375"Encrypted backups for your photos and videos"
But you show apps with images that for me implies that I can you an application you provide to look at the photos that are stored?
I dont think of Google Photo as my backup, though I presume it is that as well, but as a way to look at photos, organize them, do some quick editing, and show the same photo collection on all my devices.
Is this mostly pure backup?
Is there a means to search for photos per keyword, location, or any other meta data.
If I wish to export all photos with the keyword "Good dog" can I do that?
If so what all meta data is stored and can I adjust what I want to be revealed or not?
Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#376Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#377Although I'm not a security expert, I have some worries about your security concept.
1. When the user wants to change the password, all photos&videos have to be reencrypted and uploaded which is absurd for most people because ~100GB of photo-storage is not an exception these days anymore.
2. When your database is leaked, it is very easy to compare with leaked passwords, putting users with reused passwords in great risk.
My proposal:
Masterkey: Random key encrypted with users password
Device A creates a masterkey and short-living rolling keys. Device B creates private/pub keys. If the user wants to add another device (B), he has to enter the current rolling key (from A). Device B sends its public key to Device A, encrypted with rolling key. Device A sends back masterkey encrypted with Device B public key.
en/decryption-key = masterkey decrypted with users password
With this method a database leak would be much less of a problem and a password change much less painful.
Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#378Is there an example gallery we can check (without the need to log in, or upload own photos)? Is there a local backup? (Say, in the pessimistic case of Ente going down for any reason.)
Sorry, we don't have a sample gallery yet. :( We do have a local backup tool that will sync your uploaded files to a local folder: https://github.com/ente-io/bhari-frame/releases/latest
And is it possible to show publicly selected galleries/photos? I see only on per-person basis via email.
Right now I have an inconsistent combination of Dropbox (mostly archive), Zenfolio (public), and FB (some public) - and I am looking for a better solution (aesthetic & long lasting).
Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#379The monthly storage costs are too high. For the price of 1TB from you (15€), I can buy more than 2 TB just about anywhere else. Commercially, Apple and Google are both 2TB for 10 CHF and Amazon gives you unlimited as part of a Prime membership. Storage providers like Backblaze and Wasabi both charge around $5/TB and that's really the table-stakes price. For the more DIY-inclined, Hetzner sells a 2TB OwnCloud instance…
I can pay for a terabyte of Amazon Glacier for $50/year. Amazon Deep Glacier is $12 per month. $300/year for 2TB isn't happening. I can buy a 12TB HDD for less, if I shop around. I'd like a service like this to keep small, well-compressed 1080p or 4k photos available for instant access, and original files in archival storage of some kind. I'm totally glad to pay the $10/year for the baseline service, and another $12…
You can pay even less to store that data in /dev/null. To make a more realistic comparison you should also include data retrieval & data transfer costs. Reading a terabyte from those services costs around $100.
Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#380Earlier quoted context omitted.
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
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.