А ось посилання на її профіль в Telegram - @AmeliaTearheart.

Писати туди немає сенсу, адже вона - фейк, створений Telegram для от таких груп чи чогось ще.

Тепер на Android, як і на Desktop неможливо виділити більше 100 повідомлень за раз.

Дякуємо @tglive

Новий офіційний канал Telegram - @themes.

Теми Telegram Desktop для усіх!

Якщо ви хочете, щоб ваша тема з'явилася у цьому каналі, завантажте її до групи, Desktop Themes (t.me/TelegramThemes), із хештегом #theme.

Кілька тижнів тому я пообіцяв описати (наскільки я знаю) нову слабкість в Telegram. Немає часу для публікації у блозі, тому ось купка твітів (1/7)

Згідно з деталями Telegram, зміна ключів прямої секретності - лише обмін подвійного часу прийому-передачі (2-RTT (час, витрачений на відправлення сигналу, плюс час, який потрібен для підтвердження, що сигнал був отриманий): https://core.telegram.org/api/end-to-end/pfs (2/7)

Неефективність вбік, це дозволяє серверу Telegram невиявлено запобігти чатам від отримання будь-якої прямої секретності взагалі. (3/7)

Сервер має три методи скасування прямої секретності таким шляхом, який не пропонує будь-якого втручання сервера до Аlice чи Bob'a: (4/7)

Сервер може кинути decryptedMessageActionRequestKey, Bob'а decryptedMessageActionAcceptKey чи decryptedMessageActionCommitKey (5/7)

Сервер не може просто 'кинути' будь-яке повідомлення. Кожне повідомлення (чи сервісне повідомлення) має послідовний номер. https://core.telegram.org/api/end-to-end/seq_no (1/2)

Останній метод - найгірший: він дає серверу правдоподібного заперечення: деталі *явно* дозволяють Alice/Bob'у на невизначений час затримати CommitKey. (6/7)

Також знайшов інші атаки у Telegram, але вони залежать від реалізації. Наразі це все, надіюся, що це не нудно.

Коли приходить наступне повідомлення, клієнт бачить пропуск і запитує дані, які зникли. Чати не працюватимуть, поки не закриється пропуск.

Чому б це порядкові номери мали це полегшувати? Замість цього сервер може ввести фіктивне зіпсоване повідомлення, отже, робиться висновок, що одержувач вважає те порядкове повідомлення нерозбірливим.

Сервер не може ввести нерозбірливе повідомлення, яке буде прийнято. https://github.com/DrKLO/Telegram/blob/e313885ac540c31ea02c85122907a5845fc576d2/TMessagesProj/src/main/java/org/telegram/messenger/SecretChatHelper.java#L1534 та https://github.com/DrKLO/Telegram/blob/e313885ac540c31ea02c85122907a5845fc576d2/TMessagesProj/src/main/java/org/telegram/messenger/SecretChatHelper.java#L1564 (1/2)

І допоки не буде прийнято повідомлення з правильним порядковим номером, чат не працюватиме. (2/2)

Якщо дотримуватися цієї логіки, то усі секретні чати повинні повністю зазнати невдачі, якщо одне повідомлення неможливо буде розшифрувати. Це ж так?

Будь ласка, перегляньте https://core.telegram.org/api/end-to-end/seq_no#proper-handling-of-gaps

Це надзвичайно неефективно і важко підтримувати конструкцію протоколу. Чому ви робите це саме так? Чому б просто не зробити тріскачку ключів 0-RTT?

Вибачте, що розчарували вас створенням такого протоколу, у якому усі ваші пропоновані атаки не працюватимуть 😔