vysheng / tg

telegram-cli
GNU General Public License v2.0
6.49k stars 1.54k forks source link

Secure chat not fully working #361

Open danielberlin opened 9 years ago

danielberlin commented 9 years ago

Secure chats are not working if typing msg firstname_lastname (or msg !_firstname_lastname), I have to type msg followed by tab, then I see an ID for an already existing secure chat which looks like !_user@12345 and then I can successfully send a secure message with msg !_user@12345. However, due to README.md it should be possible to send a secure message by something intuitive msg firstname_lastname.

fgoebel commented 9 years ago

maybe outdated, but i am able to send to an existing secret chat only with msg !_firstname_lastname message

For me it does NOT work to send to a secret chat the way it is mentioned in README-LUA: [...]secret_chat#id [...]

does not work with

so is there a way to send to an encrypted chat with the ID of the Partner and not with the name?

fgoebel commented 9 years ago

@vysheng I just mentioned that secret chats wont show up if you run, dialog_list Is This intentional or a bug? It would be very usefull to have the Secret chats show up here

And i understood why it is difficult to get the secret chat with the ID, since secret chats are between two devices. So it is possible to have different secret chats with the Same user. So i think it is not implemented like it was mentioned in the Readme-lua?

Thank you for your Time!

nice regards, blast0r

danielberlin commented 9 years ago

Now, README.md states that sending encrypted messages works as follows:

msg !_firstname_lastname msgtext

Before, the secret chat id hat to be used. Could you please tell us if I have to recreate (delete it and create a new one) the secure chat to achieve this behaviour?

Before telegram-cli 1.3.1 (especially with 1.2.x), it worked only with the secret chat id. Now it tried it with 1.3.1 and it stopped working with secret chat id, but is also not working as mentioned above.

The only way it is working now is manually by using tab-completion to display the secret chat id and then use it. If I run it as batch/background process from command line by calling

telegram-cli -U telegram -p profile -e 'msg !_firstname msgtext' (this user doesn't have a last name)

it worked with 1.2.0 but not longer with 1.3.1.

$ telegram-cli -U user -p profile -e 'msg !_firstname msgtext'
Telegram-cli version 1.3.1, Copyright (C) 2013-2015 Vitaly Valtman
Telegram-cli comes with ABSOLUTELY NO WARRANTY; for details type `show_license'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show_license' for details.
Telegram-cli uses libtgl version 2.0.1
I: config dir=[/home/telegram/.telegram-cli]
> FAIL: 38: can not parse arg #1

Please tell us how is the correct way to use secret chats, either by chat id or by name and how exactly the process should be called. Thanks.

danielberlin commented 9 years ago

It is working exactly once if you do create_secret_chat. For this newly created chat, I can run visualize_key followed by tab completion and it shows me !_myuser. The key itself is displayed correctly in colorful console ASCII mode by running visualize_key !_myuser.

However, after quitting telegram-cli and restarting it, visualize_key with tab completion only shows the chat id (!_user@12345), not !_myuser anymore.

Moreover, visualize_key !_user@12345 shows an empty key (all blank white on telegram-cli).

smarnv commented 8 years ago

Just a note, secret chats are also persistent for me, but when I close and reopen the CLI, they get the name !_user_12345 (_ instead of @), where 12345 is the ID of the user you have the chat with (that you can see with user_info, for instance).

If you have multiple secret chats with the same user (e.g. from different devices of theirs), they have a suffix: !_user_12345#1, !_user_12345#2 and so on. So this answers @Blast0r. I don't know – it may have been implemented in the last year since I have just recently started using telegram-cli and haven't checked it yet.

I second what @danielberlin said – when you create the secret chats, if more than one, they work as expected – !_firstname_lastname, !_firstname_lastname#1, !_firstname_lastname#2, etc. However, this gets changed when you close telegram-cli and open it again for some reason. visualize_key works as expected when I use the user ID after it got changed.

However, I also couldn't find a way to delete secret chats (see #524) or read the history when that contact got offline before I get back online. For the latter (history !_user_12345), I receive the following error message: FAIL: 22: unknown peer. Trying history !_firstname_lastname can't parse the argument, but this is expected since it is consistent with the secret chat mysteriously changing it's name.

purplesrl commented 8 years ago

I second what @danielberlin said – when you create the secret chats, if more than one, they work as expected – !_firstname_lastname, !_firstname_lastname#1, !_firstname_lastname#2, etc. However, this gets changed when you close telegram-cli and open it again for some reason. visualize_key works as expected when I use the user ID after it got changed.

I think this is happening because the contact_list/dialog_list is not initialized when telegram-cli is started (see -W) command

I tried to start telegram-cli without the -W command and I get the following in debug:

* 1476795411.278365 Secret chat in ok state * 1476795411.278691 Secret chat in ok state

It means the secret chats are initialized before the contact_list/dialog_list

This is just a hunch for now, I will investigate more.

Update, I confirmed my first assumption:

* 1476796055.042803 Couldn't open public key file: /etc/telegram-cli/server.pub * 1476796055.043094 Can not load key /etc/telegram-cli/server.pub * 1476796055.043467 Secret chat in ok state * 1476796055.043683 Secret chat in ok state * 1476796055.459633 adjusting CLOCK_MONOTONIC delta to 0.293920 * 1476796055.635114 Reading dialog list

Update 2:

The saving of the secret chat data is done properly:

Secret chat !_Romeo updated access_hash Encrypted chat !_Romeo is now in wait state * 1476800529.701724 Secret chat in ok state * 1476800529.702173 Writing the down the name and length of the name = !_Romeo 7 Secret chat !_Romeo updated status *\ 1476800529.771602 Writing the down the name and length of the name = !_Romeo 7

And it is also read properly:

* 1476800549.299241 Secret chat id = 756898537 * 1476800549.299410 Secret chat name_length (l) = 7 * 1476800549.299536 Secret chat name = !_Romeo * 1476800549.299690 Secret chat user_id = 256313445 *\ 1476800549.299848 Secret chat in ok state

The problem is when writing it back again:

* 1476800549.299536 Secret chat name = !_Romeo * 1476800549.299690 Secret chat user_id = 256313445 * 1476800549.299848 Secret chat in ok state * 1476800549.300027 Writing the down the name and length of the name = !_user_256313445 16

purplesrl commented 8 years ago

Ok, I figured it out, the problem is loop.c, in the function bl_do_encr_chat, it is invoked as this:

bl_do_encr_chat (TLS, id, &access_hash, &date, &admin_id, &user_id, key, NULL, sha, &state, &ttl, &layer, &in_seq_no, &last_in_seq_no, &out_seq_no, &key_fingerprint, TGLECF_CREATE | TGLECF_CREATED, NULL, 0 );

When in fact it should be invoked like this:

bl_do_encr_chat (TLS, id, &access_hash, &date, &admin_id, &user_id, key, NULL, sha, &state, &ttl, &layer, &in_seq_no, &last_in_seq_no, &out_seq_no, &key_fingerprint, TGLECF_CREATE | TGLECF_CREATED, s,0 );

s = chat name l = chat name length

Now the name is displayed correctly, still you will not be able to message the peer for some reason I will have to discover in the next episode.

purplesrl commented 8 years ago

It seems some modifications to tgl/binlog.c were required, anyway I made a little patch, which I tested and it seems to work:

http://pastebin.com/EtQ5eWM6