Is Stingle Photos safe ?

[Tvirin]

Stingle Photos cloud storage for photos and videos
https://stingle.org/
https://f-droid.org/packages/org.stingle.photos/
https://stingle.org/privacy/

Stingle photos is it safe to use ?
Can it be recommended on privcyguides?
Does anyone use it, what is your opinion?

[samuel-lucas6]

They have no SECURITY.md file on GitHub, and I see no information on how to report vulnerabilities on the website.

From a very quick look at their security page:

• They use the libsodium library, which is essentially as good as it gets assuming it's used correctly.
• They seem to encrypt the private key twice using different Argon2 parameters, once for local storage and once for cloud storage.
• The claim that 'it will take nearly 1000 years to brute force 6 character password containing lowercase letters, uppercase letters and digits' is misleading and suggests it's safe to use that short of a password when it's not.
• PBKDF2-SHA512 is used by the server, not scrypt or Argon2. The number of iterations isn't specified when it should be as that's important. PBKDF2-SHA512 should use at least 100,000 iterations nowadays, despite some documentation still saying to use 10,000.
• The encrypted file headers have a flexible length, which leaks information about the length of the file name.
• The version headers are only 1 byte, which limits the number of possible versions.
• They use XSalsa20-Poly1305 as well as XChaCha20-Poly1305 for different purposes when they should just use one. XChaCha20 is slightly more secure. They're using the libsodium hybrid encryption API though that's why.
• There's no need to encrypt each chunk with a different key; they should just increment the nonce. In fact, it's not clear how they're linking chunks together or what the nonce is. This may be problematic.
• They don't describe how they get the FileID.
• They haven't listed what the ChunkSize is.
• They haven't explained the encoding or endianness of any of the headers.
• There are various typos, such as 'Public portion of the key is sent to the user's device and public is kept on the server side'.

I've probably missed something because it's late. The code needs to be looked through to establish whether there are any vulnerabilities.

[alexamiryan]

Hello Samuel,
Thanks for the feedback, we really appreciate that. Just updated the security page to address issues and missing information that you have mentioned.

To recap:

• Added SECURITY.md to the repo
• Made clarification on 6 character password to show that it's just an example and we are not encouraging to use 6 character passwords.
• Added description for FileID that it's a randomly generated value
• Added description of ChunkSize, which is 1 Mb
• Fixed typo in the last point

Now, for the other points:

• PBKDF2-SHA512 in fact is unnecessary on the server, as server receives already heavily hashed value and doing more work on the server is an overkill already. However we will consider upgrading it to Argon2 in the future.
• We encrypt each chunk with a separate key which is derived from the main key with a counter, because to play video we need to independently decrypt random chunks. We do it by having a master key and calculating chunk number.
• Good point for leaking information on the filename size. Will will create new version of file format where we pad filenames before encryption so we don't leak filename size.

If you have any more questions I really happy to answer them. Your feedback is very valuable for us.

[samuel-lucas6]

Thank you for responding to the feedback.

• I would recommend adding a SECURITY.md file to the iOS repo as well.
• The clarification is better than not having a clarification, but I think it would be best if the claim was just changed to something like 'it would take an impractical amount of time to bruteforce a strong password'.
• There should be some server-side password hashing, even if you're doing client-side password hashing, as you need some way of slowing bruteforce attacks via requests to the server.
• That makes sense, but you could also use a single key per file with a random nonce per chunk.
• Awesome.

I'll let you know if I look into it further. I'm rather busy currently.

[dngray]

Is this still developed? I noticed the Android repo seems to have not been touched since December 2021. Unusual choice to select Java there, I would have thought most modern things would have started out in Kotlin.

[alexamiryan]

Of course it’s still developed. Currently we are working on open sourcing backend code and making it self-hostable. We will have a release soon

[dngray]

This does sound exciting 👍

fyi, I'm going through the old issues here and either actioning them/or moving discussion to our more active forums https://discuss.privacyguides.net/t/stingle-photo-management/11816.

I'm thinking we might be looking at creating a section for this and https://github.com/privacyguides/privacyguides.org/discussions/187

I do see benefit of these tools, particularly when sharing photos with family members, (which are often very sensitive), and E2EE is something desired, much better than just posting it all to "Facebook" like so many do.

Likewise cloud providers really are often not designed for photo viewing.

[alexamiryan]

Thanks a lot! If you can add Stingle Photos to privacyguides.net that would be much appreciated!

[dngray]

@alexamiryan has there been any thoughts about a security audit either now or in the future?

[alexamiryan]

Yes sure. Right now we are in the process of raising money and we have already contacted with independent audit firms. As soon as we get funding we will definitely do a full independent audit