Live data from Hacker News

Show HN: We built an end-to-end encrypted alternative to Google Photos

news.ycombinator.com

371–380 of 421 posts

Re: Show HN: We built an end-to-end encrypted alternative to Google Photos

#371
post #369

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…

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

#373
post #369

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

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.

Re: Show HN: We built an end-to-end encrypted alternative to Google Photos

#374
post #373

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

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

Re: Show HN: We built an end-to-end encrypted alternative to Google Photos

#375
The first thing I read on the landing page is:

"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

#377
I think the idea is great, I'm looking for a E2EE photo service already for a long time.

Although 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

#378
post #367

Is 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

Thank you!

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

#379
post #46

The 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…

> I can pay for a terabyte of Amazon Glacier for $50/year. Amazon Deep Glacier is $12 per month.

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

#380
post #373

Earlier 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

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.

Post reply on HN