Encrypt before upload

[jorge2000x]

I do not trust 100% on telegram

[beradeep]

Hi @jorge2000x, Telegram already has slower upload & download speeds, when compared to a dedicated storage bucket. Adding an additional encryption layer, will add more overhead to the process, and can significantly slow down speeds in my opinion.

[7heMech]

Hi @jorge2000x, Telegram already has slower upload & download speeds, when compared to a dedicated storage bucket. Adding an additional encryption layer, will add more overhead to the process, and can significantly slow down speeds in my opinion.

Hey, that's true, but telegram is also 100% not private, maybe it can be opt in with a low overhead algorithm.

[rajarshikhatua100]

No one should trust Telegram with their private photos because Telegram is not end-to-end encrypted. While the uploading might be slower with the added encryption layer, it is a reasonable sacrifice. A possible solution would be to ask users during the initial app launch if they want added encryption. If they choose to add encryption, they will not be able to directly view photos or videos in Telegram.

[7heMech]

@rajarshikhatua100

If they choose to add encryption, they will not be able to directly view photos or videos in Telegram.

You've basically said the same thing as I did, but about this last part, people already can't see their images in telegram.

[rajarshikhatua100]

i see your point, sorry I was thinking about sending a photo not as a file. but either way telegram sees it. cyber security experts don't trust telegram's encryption because of it not being open source and there is not enough documentation. but that is not a problem we can solve here. and I don't know Java or kotlin (or android development in general) so i have obvious skill issues. it's kind of like this project and unlocking unlimited google photo backup in my non pixel devices where google can see my photo not telegram, it's more like a philosophical question rather than an engineering question

[beradeep]

Encryption as an opt-in feature can be added. However this needs to be tried out and tested before implementation.

[7heMech]

Encryption as an opt-in feature can be added. However this needs to be tried out and tested before implementation.

Hey, I'm not an Android dev, but I can implement fast decryption and encryption functions.

I'm thinking if they should be salted, but since they are files that could be unnecessary.

[jorge2000x]

chacha12 can be used and is very fast,we should worry about key derivation

[7heMech]

chacha12 can be used and is very fast,we should worry about key derivation

I guess we can salt them, and I don't think we'll have to worry about that.

[hlecuanda]

Adding simple encryption amounts to doing the same as the telegram devs are criticized for in the cryptography community: rolling your own. Salting is fine and dandy, but the meat of this feature is key management. How to ensure that files encrypted in one instance of the app are even usable in a different instance with a different salt (say I have 2 phones, for example) I'd like my picture to be viewable on both phones, so key management becomes an issue...

Nekogram X integrates with OpenKeychain, a PGP app. So far it allow you to share your public keys and import other people's keys, also use them to encrypt messages using PGP and it's algos. Further integration is being worked on, to allow automatic PGP encryption and signing of messages on the fly, but it's not quite there. (Other messaging apps, notably conversations and K9 mail, so a deeper integration is possible)

This has the obvious advantage of having a mature encryption technology and key management offloaded to a dedicated encryption app instead of "rolling your own" (which is the objection to telegram's encryption method, because it is documented and open sourced, contrary to popular belief.)

[7heMech]

Okay, so this is what I think:

Key Derivation:

• When a user enables image encryption, prompt them to input a strong password or passphrase.

• Using a robust key derivation function (KDF) like PBKDF2, bcrypt, or scrypt derive a strong encryption key from the user's password.

• The KDF should be computationally expensive and include a salt to protect against rainbow table attacks, show the salt to the user so that they save it or maybe send it in telegram, we don't care if telegram knows it since it's to protect against rainbow tables.

Secure Key Storage:

• Store the derived encryption key securely on the user's device using Android's KeyStore.

Encryption:

• Encrypt each image using AES-GCM from javax.crypto and the stored encryption key before uploading it to the telegram server.

[beradeep]

@7heMech great feedback. I was thinking in a similar way, but instead of a new password, I think using the bot token itself would suffice. It'll also be stronger than any password entered by the user.

[jorge2000x]

We should use argon2 instead of pbkdf2 or bcrypt because it is more modern and secure...
The salt could be related to the group or bot, if you change phone the salt is the same and continues to protect from rainbown table, using the bot token to encrypt would be basically useless because telegram would know what the password is, to simplify when creating the password, the application would indicate the creation of a passphrase of 6 or 8 words, which is extremely secure.

[jorge2000x]

In addition, chacha20 is faster than AES, unless the device has hardware acceleration, but in general chacha20 is faster(or even chacha12 but no)

[7heMech]

@7heMech great feedback. I was thinking in a similar way, but instead of a new password, I think using the bot token itself would suffice. It'll also be stronger than any password entered by the user.

Yeah, as the comment above pointed out, bot token can be seen by telegram, and refreshed unfortunately, but we can use bot id as a salt! (still not sure about this, since there should be no problem to even change the bot, that's why I was thinking about adding salt to name of each image or something like salting with the unix timestamp)

[7heMech]

In addition, chacha20 is faster than AES, unless the device has hardware acceleration, but in general chacha20 is faster(or even chacha12 but no)

Fair I enough, I took a look at it, we can use that, how about we open a draft pr for this?

[7heMech]

I've done 0 kotlin development, but maybe I can make a utility class which encrypts and decrypts data + maybe store and get key.

So we figured out to use:

• Argon2 - to derive key from passphrase
• ChaCha20 - to encrypt files
• Salt - unknown maybe unix timestamp

[jorge2000x]

Which libraries could we use? I was looking at libsodium but i didnt searched about. Create a fork to start working

[beradeep]

@jorge2000x @7heMech, your concerns regarding the bot token being known to Telegram are valid, but I think even if Telegram happens to collect data from images, we can safely assume that they won't go out of their own way of data collection and start decrypting files using the token just for whitehole users.

[beradeep]

Also, imo using AES would be easier to implement as almost every language has support for it, and afaik Java definitely does.

[7heMech]

@jorge2000x @7heMech, your concerns regarding the bot token being known to Telegram are valid, but I think even if Telegram happens to collect data from images, we can safely assume that they won't go out of their own way of data collection and start decrypting files using the token just for whitehole users.

The real problem is bot token is resettable a better option would be bot (or even better user) id.

[jorge2000x]

When you're going to implement something as complex as cryptography, the ideal is to do it in the most robust way possible, using the token as a key is easier to implement, and can be secure for a while, but then, what if telegram "traps" the data and reads the whitehole documentation... cryptography has become useless, unfortunately we have to do it the right way (by the way, encrypting with the token, another device could decrypt too? ) Using the token as salt is considerable, about AES, fine, it's robust, but I considered chacha20 before because it's faster.

[7heMech]

@jorge2000x yes, but the token is easily resettable, what if the user accidentally deletes, also I'm talking about salt here, we should do proper derived key from passphrase + id/token etc.

[beradeep]

@7heMech I don't think the token being resettable is the real problem though as the app at its current state would stop working if the token is reset. Rather as @jorge2000x mentioned, the security can be a problem.

[beradeep]

I think we can also use the unique id i.e. chat id as the salt along with a passphrase.

[7heMech]

I think we can also use the unique id i.e. chat id as the salt along with a passphrase.

Yeah, that's the best move, dunno how I didn't think of that.

[jorge2000x]

I think we can also use the unique id i.e. chat id as the salt along with a passphrase.

The best option.