search

marcovelon / tdesktop

Telegram Desktop messaging app without end-to-end encryption
https://desktop.telegram.org/
Other
10 stars 2 forks source link

[Feature Request] Secret Chats in Telegram Desktop #2

Open marcovelon opened 2 years ago

marcovelon commented 2 years ago

This issue is a continuation of https://github.com/telegramdesktop/tdesktop/issues/871 and https://github.com/telegramdesktop/tdesktop/issues/16835 and is dedicated to the code bounty campaign related to lack of implementation of a Secret Chat feature (end-to-end encryption in private messages) in Telegram Desktop.

The objective is to implement the Secret Chats feature into this Telegram client: https://github.com/telegramdesktop/tdesktop

It is possible to do it with 3 different ways (but not limited to):

This code bounty doesn't limit the programmer to any specific way of implementation, as soon as the final result will make possible to use Secret Chats on the open source Telegram Desktop (tdesktop) client on Linux and Windows in the exactly same way as it's done in mobile clients.

UPDATE 04/2022 / Funds distribution scheme:

There will be 3 payouts based on completion of the following stages:

The developer(s) will receive 1 ETH for completing one of the stages from the list above, totalling 3 ETH for all stages. The source code should be available and compilable.

The adjacent functionality such as deleting and configuring Secret Chat options can be done during any phase of the work progress described in the list above, however it must be done before or with 3/3.

I have created a verified signature for my Ethereum address containing the funds for this issue: https://etherscan.io/verifySig/4431 (https://etherscan.io/address/0xd19ee4a49b9214c4c22694bb01f225baf35f6efc)

Any voluntary donations are welcome. You can send them to the address above.

My email for communication is marcovelon@protonmail.com

CURRENT PROJECT FUNDING:

The overall funding now is 13000 USDC and 1.18 ETH (~3929 USD)

sergiotarxz commented 2 years ago

I just reported that issue https://github.com/telegramdesktop/tdesktop/issues/24540

sergiotarxz commented 2 years ago

I have been answered and it wasn't like I thought from reading the code the random server sequence was later xor with a client random sequence creating a new key and from that modexp aka g_a was get.

sergiotarxz commented 2 years ago

I am implementing the dh key exchange still, it is harder than I thought, fortunately most is already done in the mtproto implementation, I wish I was more proficient with c++ but I am having to do it in small steps. Anyway I feel capable to complete the job.

sergiotarxz commented 2 years ago

I just achieved to create a secret chat from telegram desktop, but there is nothing which can be done yet.

sergiotarxz commented 2 years ago

I just commited what I achieved by the moment https://github.com/sergiotarxz/tdesktop there is still a lot to be done, but I managed to organize all the secret chats code made by the moment into a .cpp and .h file which creates an object Secret::Secret which is going to be the core of the support of Secret Chats. You can now establish E2EE chats from telegram desktop, but nothing more can be done and those chats do not appear as listed.

marcovelon commented 2 years ago

@sergiotarxz awesome, I've compiled it and it works for requesting and estabilishing a SC session. Once you also manage to make code to autoaccept an incoming SC request, please post your ETH address, since I will have to transfer you 1 ETH for completing this:

[1/3] Estabilishing Secret Chats via DH key exchange (ability to send and accept Secret Chat requests)

BTW it seems you forgot to add lng_profile_start_secret_chat to Telegram/Resources/langs/lang.strings in the commit, but I managed to add it locally in order to compile.

sergiotarxz commented 2 years ago

Hi, the error you pointed is already solved. My ethereum address is 0x411CC8c2D3f09D23f602112352d8012757ACB753, I am trying also to get the chat listed in the UI before he first payment.

marcovelon commented 2 years ago

Would you consider to prioritize adding a possibility to accept incoming SC request before adding the UI? It's still the undone part which is important too. (I mean, from "send and accept Secret Chat requests" only the "send" part is done for now, since the client can only request SC but not accept them, so the 1/3 is only half-complete)

sergiotarxz commented 2 years ago

Well then I will do that first, I started the UI code already but I can leave the changes I already did for later and start with accepting requests.

sergiotarxz commented 2 years ago

I have completed the first phase, it is available at my github repo, if you have it already cloned run git pull --rebase. @marcovelon

Well I would want to give some words about my achievement, when I started the project I didn't know if I was going to be able to tackle such challenge in a foreign codebase written in a language I do not master, now 9 days later I feel more capable of changing things in tdesktop.

I still have many things to learn about tdesktop, for example the way to persistent store the final keys for the chats for further usage, but I think pretty much the hard thing to learn is learnt.

marcovelon commented 2 years ago

I must say I really appreciate that you started working on it @sergiotarxz . Your skill level is exactly what I expected from a coder to address this issue. Clean code and professional approach.

1/3 is complete and I've just sent 1 ETH to your address. Nice work!

sergiotarxz commented 2 years ago

Thank you so much, it is such a generous payment for a 9 days job in my country. I will keep contributing further I will keep going until the secret chat thing is completely done.

marcovelon commented 2 years ago

Well I'd say everyone could agree here it's not just a trivial 9 days job, since a whole Telegram's team of coders couldn't make it in 8 years and their tdesktop team considers it as some impossible rocket science task. While I disagree with them on how they describe its complexity, it's still for sure a task that not any coder could complete that quick. It requires certain training/experience and it turns out it's quite rare today to find such people, so your experience should always be valued adequately, anywhere. I wrote the whole story about this issue here: https://github.com/marcovelon/tdesktop/blob/NoSecretChats/README.md

sergiotarxz commented 2 years ago

I read that text, but I disagree with some of the answers this text provides to the telegram complains for example it is true that storage is "safer" in android because applications can have private data to the other applications, but this can be evaded if you use telegram in flatpak or if we implement some kind of encrypted sqlite database that needs to be decrypted with a user secret, also if you trust your software because it is Free Software it isn't a problem either.

I think it is better to have E2EE although you have not client security that not having it at all.

marcovelon commented 2 years ago

I understand that Android storage security has some perks, but the main reason why I wrote that one is because I personally use firejail to sandbox apps like Telegram and there are also many other solutions to this, like flatpak as you said. And since their team generalize the whole stuff to their very specific manner by blatantly discarding us, FOSS users, and our preferences, I decided to generalize it as well, however ofc I understand that it's not the full answer and could be improved.

sergiotarxz commented 2 years ago

Hi, there have passed 3 days since my last post so I thought it would be a good idea to tell how the progress is going in the second phase.

I am getting issues to get encrypted peers listed in the ui and opening chats with encrypted peers so I am still working on that.

I thought I knew enough the codebase, but the true is I do not so I am trying to do small steps to hopefully understand what is going on and why my peers do not get listed.

I am seriously thinking about getting a new computer since the one I have compiles soooo slow the telegram desktop code when I modify peer headers.

Sorry for not being reporting my no progress the last days.

I do not know if telegram desktop developers stick in some irc channel or something like that but I could make use of a talk about the ui architecture of the app with them.

marcovelon commented 2 years ago

AFAIK they don't use any chatting platform for dev discussion and their devs maintain full anonymity under the @john-preston github handle. I just found #telegram and #telegram-foss on Libera with a few people but it's very unlikely we will meet any official devs there, since they probably use Telegram only.

Anyway I wouldn't recommend engaging depthly with any of them on this topic, because toxic russian devs like ilya-fedin and their sockpuppet aokromes have a weird tendency of ridiculizing those why try to discuss this topic or implement it, which is quite suspicious. Idk what could be the exact reason, but I suspect it's either jealousy that they lack the skill to do so or their sponsors tell them behave like that, and given this they may purposely technically mislead a coder who will be trying to implement it. Also the fact that all of them are completely anonymous brings some weight to my presumptions, not even mentioning that in their official subreddit they automatically delete the posts related to this topic. This all may sound as a conspiracy theory, but there is actually a reason for it since their community is not transparent and leaves a lot of unknown. They can keep trying to refute this as long as they want, however the fact that there are 8 years without Secret Chats in Telegram Desktop is still a fact, thus they better change their behaviour and stop ignoring and censoring this topic. I am sure the only response you will get from them is their typical "secure chats is difficult to implement and we can't do anything about it because it's not based on TDLib", so it's a bit pointless to even ask there, because we already did several times during past 8 years.

sergiotarxz commented 2 years ago

Well, today I achieved to open in the gui for the first time a secret conversation although nothing can be done with it, no sending messages, no seeing messages, but it is a great achievement since there have been a couple of days without achieving nothing and this will help to unstuck the development.

dm17 commented 2 years ago

Well, today I achieved to open in the gui for the first time a secret conversation although nothing can be done with it, no sending messages, no seeing messages, but it is a great achievement since there have been a couple of days without achieving nothing and this will help to unstuck the development.

Great job! Congrats!

sergiotarxz commented 2 years ago

Just checking the code I saw the code assumes in way too many places that messages are of the kind MTP_message which is no longer true and it also assumes that can ask for Peer data to the telegram server like settings, history, etc for anything that inherits from PeerData which is also no longer true since encrypted chats are no longer a Peer.

I am trying to workaround that with if discarding to do that for encrypted chats, but the second part is proving itself every day to not going to be a easy job.

Also every time I have to touch the PeerData header I have to recompile almost the complete project so meanwhile I get my new computer the development will continue to advance in a very slow pace.

sergiotarxz commented 2 years ago

You may belive it or not, but the only achievement I did since the last screenshot is showing the peer name in the encrypted chat and it was so difficult to me that I almost took the day off. I am not commiting the changes since I have been touching in so many places to achieve that and created so many debug code that removing all the unneeded code to create a clean commit is a really hard task. (I will have to do it some day anyway.) Now the ideal would be to achieve to show the message sending ui for the next iteration.

sergiotarxz commented 2 years ago

Well, I overestimated the hardness of commiting there were only debug changes on a couple of files so you can check the code if you want.

sergiotarxz commented 2 years ago

Now in the latest commit at https://github.com/sergiotarxz/tdesktop includes the ability to look into the secret chat "profile" and "send messages" ui options.

This is a stub, but it will serve as the building block of the core features of the part II of the bounty.

I think the hardest has been done but I may be wrong.

sergiotarxz commented 2 years ago

I am struggling to get the group behavior in secret chat.

This is what I am trying to achieve:

I asked in this issue to tdesktop team https://github.com/telegramdesktop/tdesktop/issues/24581 seeking for advice, I am investigating further, but if we could use their advices that would be ideal to avoid being stuck in that.

sergiotarxz commented 2 years ago

I just saw that if I wanted to merge into telegram desktop I should sign a CLA that gives Telegram the code under the public domain which potentially allows them to create privative spin offs of the software. (The project license is GPLv3 so only Telegram would be able to do it.)

sergiotarxz commented 2 years ago

I asked john-preston in person by Telegram I was pointed to his account at TelegramDesktopTalk, they said that the secret chat feature is wanted but difficult to implement with the custom tdesktop mtproto implementation.

sergiotarxz commented 2 years ago

Good news is that I reach the quality standards of tdesktop the code may get merged when finished.

marcovelon commented 2 years ago

@sergiotarxz: I asked john-preston in person by Telegram I was pointed to his account at TelegramDesktopTalk, they said that the secret chat feature is wanted but difficult to implement with the custom tdesktop mtproto implementation.

I am not surprised, since this was their template answer and a reason for not implementing SC for last 8 years. I have read carefully every issue (actually that's more than 100 issues) from their repo regarding the subject and "we want it but we can't because too difficult" is mostly just a default answer of them, also considering Durov's wealth and him unable to sponsor fixing one critical issue in his own messenger is something extremely suspicious.

However we shouldn't worry what they say about this anymore, because this commit already proves them wrong :-) considering how quickly it was done and that it's only 1 step till the ability of sending messages will be done, which will happen to be accomplishing the most difficult part (cryptography-related stuff).

Generally speaking, their excuses to not work or even help on this issue are no more relevant at this point and their lack of skill in this context shouldn't be an obstacle here, because me and others have already asked them for help before you started working on this and there was absolutely nullous feedback, not even mentioning how many people they (ilya-fedin, aokromes and others) ridiculized in a really toxic way for simply trying to do something in this regard, making them losing motivation to work on this and quit to another project... These people only criticize pointing how wrong someone is, while never giving any useful information or doing anything useful in this context. If john-preston is an actual person then probably only he/she can provide any relevant help and I hope he/she can help you somehow, since the rest of the contributors don't have sufficient skills to dig into this issue and tend to just follow preston's opinion, which will most likely change in the near future. TL;DR: relying on their help in this context is a waste of time, and if it wasn't, I wouldn't have to create a separate repo just for this issue... Also, considering that many of them are aware of this topic existence since its creation (since it's cross-referenced with another huge issue in their repo), there is no single message from them here in this topic. This fact itself says a lot.

Now on-topic:

This is weird that the p2p chat is identified as a group chat in UI, since it really shouldn't.

Maybe you can try shortcutting this by avoiding UI-related stuff for now and try to make the client sending back an encrypted message right after accepting a secret chat in a bot-style like that: 1. accept secret chat request 2. automatically send an encrypted message to the peer of the new chat id without interacting with UI ? This would make it possible to postpone the UI-related stuff and at least ensure we have working encryption first. It looks like it's more like UI-related confusion here that can be postponed for later, because if we will have at least encrypted sending working, it will significantly facilitate UI debugging.

sergiotarxz commented 2 years ago

The idea it is not to secret chats to act like group chats, but instead to copy some of their UI unique features like appearing immediately after you start belonging to them.

I agree with attempt message exchange before continuing with those UI problems because they are proving to be difficult to solve and the current UI status already allows to get our hands dirty on that since we can both in UI use the send and receive functionalities with little change.

sergiotarxz commented 2 years ago

Preston doesn't offered to help he answered my question with a plain "idk".

dm17 commented 2 years ago

@sergiotarxz: I asked john-preston in person by Telegram I was pointed to his account at TelegramDesktopTalk, they said that the secret chat feature is wanted but difficult to implement with the custom tdesktop mtproto implementation.

Yes, their behavior has been transparently obfuscatory and basically how counter-intelligence people would act the entire time. I'm not saying the western equivalents like WhatsApp aren't just as bad - and who knows if Telegram can be considered Russian anymore now that they're based in UAE and Ukraine openly seems fine with getting a large part of their news from Telegram news channels (no claims being made about the war here other than it doesn't make sense that Telegram is so widely trusted as a source in Ukraine when it would supposedly be within Russian control to some extent).

sergiotarxz commented 2 years ago

I am right now working on encrypt a decryptedMessageLayer object.

Upstream opinion:

I am not sure about if it is really counterintelligence or lack of interest and I don't mind, I will attempt to get merged my code upstream once I have cleaned it up the obvious thing would be if the merge it is not in a mergeable state they should point what else have to be improved in order of it to be merged if they work like a common Free Software project if they don't then maintaining a fork would be necessary.

ilya-fedin commented 2 years ago

Also, considering that many of them are aware of this topic existence since its creation (since it's cross-referenced with another huge issue in their repo), there is no single message from them here in this topic. This fact itself says a lot.

Well, secret chats is not something I personally need, so I forgot about this topic as soon as it got out of tdesktop repo... And I only remembered now as @sergiotarxz reached TelegramDesktopTalk and sent the link.

because me and others have already asked them for help before you started working on this and there was absolutely nullous feedback, not even mentioning how many people they (ilya-fedin, aokromes and others) ridiculized in a really toxic way for simply trying to do something in this regard, making them losing motivation to work on this and quit to another project... These people only criticize pointing how wrong someone is, while never giving any useful information or doing anything useful in this context.

Maybe I'm missing something but I don't see any ask for help (concrete questions about the code) in your issue in tdesktop repo as well as I don't see any toxicity. Vice versa, I see preston's answers and aokromes closed your thread only after you decided to move your thread to a separate repo.

However we shouldn't worry what they say about this anymore, because this commit already proves them wrong :-)

Actually, I remember preston said that crypto is not the problem. The problem is the infrastructure. The person who would want to implement the feature in tdesktop would need to follow some guidelines (I don't know which ones exactly, that's a question for preston) on the mechanics, messages database, UI and etc. Without all that the feature will be just incomplete and unmergable. So if getting the feature upstream is the goal, the person who does the work should work closely with preston (ask what's needed & code reviews) on early stages in order to avoid rewriting the code. As preston rarely reads github, the best option is to do that via private messages on Telegram ofc.

work like a common Free Software project

Let me quote preston:

it may break opensource, but it doesn't break open source, probably.. the goal is not initially in "developed by community", the goal is in open source clients, in potential audits and confidence of how secret chats are working..

it's a little joke.. it's just they're reaching github and saying — why there's no this, no that, it's opensource, they don't mean "open source" literally, they mean something other, some development approach.

I'm saying source code is open doesn't mean that development happens in a defined process, e.g. the community decides what to develop next or something like that.

But preston is not against accepting PRs in general (I'm asking the details on how something should before doing anything, what's acceptable and what's not and that works after all, he usually accepts). I remember he once said that he usually need to rewrite anything people do in PRs as they do it wrongly and that's why he doesn't usually like when someone PRs something. That's one more reason to consult in early stages.

If john-preston is an actual person

He is an actual person. Moreover, every their client has only 1-2 developers. And preston is the most loaded from them as he writes on a low-level language and for three systems (that's why there are missing features, he just can't get them in time and then he should implement new features, don't even remember bugs).

sergiotarxz commented 2 years ago

I wouldn't like to give preston the impression that he is going to need to rewrite a big part of the pull in case I got merged, I would prefer a lot to be code reviewed and do the needed changes myself, I am aware that this is a big development so I would not be in a hurry to be merged when the moment reachs.

I sent a message to preston before and I was answered by an acronym and that gave me the impression that my message was not welcome and I wouldn't like to get preston annoyed with unsolicited private messages.

ilya-fedin commented 2 years ago

rewrite a big part of the pull in case I got merged

He doesn't merges and then rewrites, he just doesn't merge (and rewrites the code as he sees fit if it's something he is interested in).

ilya-fedin commented 2 years ago

I sent a message to preston before and I was answered by an acronym and that gave me the impression that my message was not welcome and I wouldn't like to get preston annoyed with unsolicited private messages.

Well, answering with an acronym is something common in messengers. Especially when you talk to a non-native.

sergiotarxz commented 2 years ago

I sent a message to preston before and I was answered by an acronym and that gave me the impression that my message was not welcome and I wouldn't like to get preston annoyed with unsolicited private messages.

Well, answering with an acronym is something common in messengers. Especially when you talk to a non-native.

Can you explain about answering non-natives with acronyms as something common?

I didn't find any internet sources that explains that behavior and I am not really good with social culture on english speaking countries with not natives or social culture in general.

Does it means that I am supposed to keep asking Preston without it annoying him?

ilya-fedin commented 2 years ago

Can you explain about answering non-natives with acronyms as something common?

He is a non-native English speaker, I don't think he put some other meaning rather than "I don't know" in "idk"

ilya-fedin commented 2 years ago

He is also a busy person, so it's not a rare situation when he forgets to answer or forgets something to do.

sergiotarxz commented 2 years ago

I am right now getting rate limited by telegram to open secret chats, I tried putting my own api key, but that didn't make me free of that rate limits. I have almost complete the send of encrypted messages.

sergiotarxz commented 2 years ago

I had my first success sending encrypted messages but they don't appear listed yet.

sergiotarxz commented 2 years ago

I achieved my encrypted messages to appear listed.

sergiotarxz commented 2 years ago

You can checkout the changes in https://github.com/sergiotarxz/tdesktop do:

## If you do not have it checkout:
git clone https://github.com/sergiotarxz/tdesktop --recursive
## If you have it checkout:
cd tdesktop
git pull --rebase
git submodule update --init

And compile to try it.

sergiotarxz commented 2 years ago

Currently in the moment you create a secret chat a encrypted message is send with the hello world content.

sergiotarxz commented 2 years ago

I am fixing some things that were not mean to commit, please wait.

sergiotarxz commented 2 years ago

Those things were already fixed.

sergiotarxz commented 2 years ago

I discovered that creating global hashes of secrets was a really bad idea since opening a secret chat with an account in your tdesktop from an account in your tdesktop makes one's secret to overwrite other's secret, I am fixing that putting the secrets at Data::Session level, that hopefully will fix the problem I am facing.

arch-btw commented 2 years ago

Great job @sergiotarxz very impressive! Will try to compile it tonight.

sergiotarxz commented 2 years ago

I am almost done with decryption. (No UI code still.)

sergiotarxz commented 2 years ago

I achieved to decrypt the first message coming from tdesktop in tdesktop, although the code is now breaking when android secret chat reachs tdesktop, when I fix that I'll commit.