Update Precompiled Android libs so Secret Chats work again

[CompSciFutures]

After much investigation it is clear that the current Prebuilt Libraries for Android available here are out of date:
https://core.telegram.org/tdlib/tdlib.zip

The main issue is that using TdApi.CreateSecretChat & TdApi.SendMessage intermittently delivers secret chat messages, and even when a message delivery is successful, sometimes the message delivery notification appears on the destination device but the message doesn't actually appear.

This behaviour is mentioned in the following issues:

• Incoming messages are not appearing for one channel and flowing in for other channels
  Incoming messages are not appearing for one channel and flowing in for other channels #2709

• SecretChat
  SecretChat #1060

The current Prebuilt Libraries for Android are dated Dec 29, 2021 and since then numerous critical security vulnerabilities have been found in OpenSSL which I imagine has been patched on the server side, but has introduced some compatibility issues with the currently available Android client. This is also a potential security problem linking the client against an old version of OpenSSL. A list of recent vulnerabilities in OpenSSL are available here:

https://www.openssl.org/news/vulnerabilities.html

Can you please provide an updated version of the Prebuilt Libraries for Android so that end-to-end encrypted Secret Chats work reliably again and to ensure there are no problems with the old version of OpenSSL that is currently linked with the available library.

Thanks!

.\p

[CompSciFutures]

Also you might want to consider BoringSSL. The world is moving away from OpenSSL as the code base is too complex and the attack surface is proving unmanageable and fundamentally insecurable. BoringSSL was written by Google to address this issue and the API is almost a 1:1 drop in replacement.

It is also recommended that one uses 4096-bit public key exchange. A 1024 bit DH or RSA key exchange generates >= 80 bits and <= 96 bits of key material which is then zero-padded before being used as a symmetric key for the subsequent AES-128 encrypted channel that opens. AES-96 is not very strong, and zero-padding the key makes it even weaker.

Also AES-128 is no longer considered particularly strong by today's standards. One should use at least AES-256 or ideally AES-512 where possible. The latter would require an ECC key exchange of significant length as it is computationally onerous to generate such key lengths using classical asymmetric key exchange such as Diffie-Hellman or RSA.

[levlam]

There were no fixed OpenSSL security vulnerabilities that affect TDLib.

TDLib supports building with BoringSSL instead of OpenSSL, but this isn't recommended. https://github.com/google/boringssl/blob/master/README.md: "Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it."
BoringSSL also has some changes, which negatively affect TDLib's security.

Other thoughts about used encryption are also irrelevant.

You can build the latest TDLib for Android following https://github.com/tdlib/td/tree/master/example/android. Precompiled binaries will be deleted with the next minor TDLib update being surpassed by the example.

[CompSciFutures]

Re-enabling SecretChat: Merits of upgrading & caveats

Upgrading worked, secret messaging is now a thing again - thanks for your help.

It is however a bit more difficult with the new API to transition all past chats into a "Secret Chat Cancelled" state when one uses Destroy(). I find this deceptive from the user perspective, but I can understand how this would be more efficient at the server side by requiring less statefullness to be cached. However, switching between previous binaries and fooling around with version numbers indicate the requisite data is being store anyways so the efficiency/performant argument is moot.

You are clearly logging everything and keeping it in a stateful structure at the ready.

Which begs the question, why doesn't LoadChats() actually load the list of chats? The data is there, so the only upside is identity hijacking. Stop obfuscating.

I think you need to prove you aren't just another NSA drone and do the obvious things that are materially useful for user safety & privacy and stick to it. Otherwise, your demise soon draws near. I.e., always do the right thing: right now, you are not.

API Noise or: How you learned to stop securing and love UX

Also the following server messages are very noisy since the update - please don't make the mistake of UX over user safety:

TdApi.UpdateInstalledStickerSets ||
TdApi.UpdateAccentColors ||
TdApi.UpdateProfileAccentColors ||
TdApi.UpdateAnimationSearchParameters ||
TdApi.UpdateActiveEmojiReactions ||
TdApi.UpdateDiceEmojis ||
TdApi.UpdateChatThemes ||
TdApi.UpdateTrendingStickerSets

(Erich is doomed and SVCode is being developed as we speak, with proper security protocols in place - don't be VSCode).

Rebuttal

As "irrelevant" as you claim my comments about encryption might be, they certainly are salient and relevant and your dismissal is telling, thus I must elaborate:

• The API provides no visibility into the cryptosystem, key strength or any way of verifying signatures for secret chats, which leaves one open to direct cryptographic trapdoor attacks and to MITM attacks when doing end-to-end encryption.

• I posit that the current implementation of Telegram has actually been intentionally weakened and that calling it "end-to-end encryption" is a stretch - prove me wrong.

I welcome you to prove me wrong on the above. And so would your users. Make me the bad guy by making your API better and proving me wrong.

Moving forward for the benefit of all

Let me know if you want to discuss further on how to harden the protocol. The current changes are diverging away from a security by design, secure by default philosophy and cannot be trusted for secure e2e communications in it's current form.

At least it does however work (in it's currently debilitated realization of a once grande ideal).

Given recent press about Telegram defaulting to insecure communications, perhaps we should have the conversation about how to make it more secure?

@see https://medium.com/secure-words/your-messages-on-telegram-are-not-encrypted-the-platform-is-not-as-private-as-you-think-d14a6342928d

I'd hate to think that you were eaten by wolves without appropriate due-diligence. I don't mean to get zk-SNARKy, but:

• PS. ECDSA is a crock.
• PPS. Argon2 is cool - use it.
• PPPS. OpenSSL is an NSO sploit waiting to happen. You can't guarantee "no vulnerabilities"
• PPPPS. It surprises me that you have financial hooks in the User/UserFullInfo objects but no means of verifying the various elemental components relating to financial transactions. Do you even Banking bro?

Epilogue:

I don't offer any apologies if the above offends your agenda, but please accept my most humble and apologetic assistance if you motivation and execution is pure. If would like me to lean in and make Telegram better; like a properly open competitor to "AGPL" Signal (pft! socialists!), then please do.

If you don't release a truly open and practically useful API, then we will build something into SVCode to replace you, Signal, Whatsapp and Telegram that resolves the metadata problem once and for all and is truly open, secure, safe and grounded on the sound principles of hyper-accelerated capitalism.

Fin:

Best Regards,

.\p on CS

[levlam]

By the way, secret chats must work in the precompiled version with any up-to-date Telegram app. If they don't then a ticket must be created against the app with which they don't work.

To avoid MITM you just need to compare secretChat.key_hash with the other party.

[CompSciFutures]

I'll check it out.. 👍

[CompSciFutures]

So, how does one find secret_hash in the regular IOS/Android UI? And what about cryptosystem info?

[levlam]

You can check the key as documented: "This is a string of 36 little-endian bytes, which must be split into groups of 2 bits, each denoting a pixel of one of 4 colors FFFFFF, D5E6F3, 2D5775, and 2F99C9. The pixels must be used to make a 12x12 square image filled from left to right, top to bottom. Alternatively, the first 32 bytes of the hash can be converted to the hexadecimal format and printed as 32 2-digit hex numbers"

[CompSciFutures]

Thanks... that's useful.