Как лучше защить трафик Telegram

Я рекомендую age.

age - это пример того, что может получиться у профессионального криптана, который ни черта не смыслит в разработке программного обеспечения, и толпы восхищающихся им идиотов. Переусложненная (при том что заявлялась как простая альтернатива gpg) хрень с референсными реализациями на го и расте, просто кровь из глаз.

Ладно, парни, не заморачивайтесь. Понимаю, что тема непростая, а некоторым она вообще не по вкусу и поэтому их раздражает.
Конечно, я бы задал вопрос на традиционном pgpru.com, где было полно знатоков по безопасности, но там сейчас пустыня.
К сожалению, интерес публики к данной тематике с годами угас, или она переместилась в соцсети, фиг его знает.
Попробую поискать альтернативные сайты, если такие еще есть.

А зачем использовать специфичное для приложения проксирование трафика, если можно завернуть весь трафик устройства в VPN? Или идея спецом один конкретный трафик гонять через прокси? Тогда мне прям интересно, почему именно трафик телеги так должен ходить?

Если трафик Телеги методом перебора вскроют, условно говоря, через 2^128 лет, то дополнительное шифрование, тоже условно говря, отодвинет этот срок до 2^256 лет.

Не совсем, скорее 2^128 лет + 2^128 лет.

age простой настолько, насколько вообще может быть. Если он для тебя сложный, у тебя проблемы с компьютерной грамотностью.

Шутка, наверное? :=) Речь ведь о телеге и защите ее трафика. Или я чего-то тут не понял…

Какие шутки? Если у вас принцип «кашу маслом не испортишь», то

1. Настроить прокси на работу через Tor
2. Настроить прокси на работу через ShadowSocks

Какой их этих способов лучше защищает трафик Телеги, и почему?

Это ложный выбор. Вам нужно:

3) Телеграм в Tor, Tor в ShadowSocks.

age простой настолько, насколько вообще может быть

это у тебя проблемы с компьютерной грамотностью, чудик)

Это сказал человек, не осиливший программу с 8-мью опциями, хелп которой помещается на одну страницу. Не позорься уже.

Usage:
    age [--encrypt] (-r RECIPIENT | -R PATH)... [--armor] [-o OUTPUT] [INPUT]
    age [--encrypt] --passphrase [--armor] [-o OUTPUT] [INPUT]
    age --decrypt [-i PATH]... [-o OUTPUT] [INPUT]

Options:
    -e, --encrypt               Encrypt the input to the output. Default if omitted.
    -d, --decrypt               Decrypt the input to the output.
    -o, --output OUTPUT         Write the result to the file at path OUTPUT.
    -a, --armor                 Encrypt to a PEM encoded format.
    -p, --passphrase            Encrypt with a passphrase.
    -r, --recipient RECIPIENT   Encrypt to the specified RECIPIENT. Can be repeated.
    -R, --recipients-file PATH  Encrypt to recipients listed at PATH. Can be repeated.
    -i, --identity PATH         Use the identity file at PATH. Can be repeated.

INPUT defaults to standard input, and OUTPUT defaults to standard output.
If OUTPUT exists, it will be overwritten.

RECIPIENT can be an age public key generated by age-keygen ("age1...")
or an SSH public key ("ssh-ed25519 AAAA...", "ssh-rsa AAAA...").

Recipient files contain one or more recipients, one per line. Empty lines
and lines starting with "#" are ignored as comments. "-" may be used to
read recipients from standard input.

Identity files contain one or more secret keys ("AGE-SECRET-KEY-1..."),
one per line, or an SSH key. Empty lines and lines starting with "#" are
ignored as comments. Passphrase encrypted age files can be used as
identity files. Multiple key files can be provided, and any unused ones
will be ignored. "-" may be used to read identities from standard input.

When --encrypt is specified explicitly, -i can also be used to encrypt to an
identity file symmetrically, instead or in addition to normal recipients.

Example:
    $ age-keygen -o key.txt
    Public key: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p
    $ tar cvz ~/data | age -r age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p > data.tar.gz.age
    $ age --decrypt -i key.txt -o data.tar.gz data.tar.gz.age

а, так ты в спеки с исходниками не смотришь. Ну так бы сразу и пояснил, что не знаешь о чем говоришь.

У меня слишком короткая жизнь, чтобы смотреть в исходники всех используемых мной инструментов без нужды. Пока ты ничего кроме какой-то непонятной истерики не развёл в этой теме. Если у тебя есть какие-то конкретные претензии, выкладывай (со ссылками в issues соответствующих проектов). А пока я вижу только необоснованные ничем наезды на прекрасный проект, использованием которого я искренне наслаждаюсь после ужасного gpg.

У меня слишком короткая жизнь, чтобы смотреть в исходники всех используемых мной инструментов без нужды.

Мудрые слова, подписываюсь.
Хотя я сам вообще в них не лезу :=) По той же причине.

пока ты наслаждаешься, этот прекрасный проект отправит страницу памяти с твоим секретным ключом в своп, откуда его сможет достать кто угодно. Чудики просто не подумали об этом, бгг

А тикетов я не создавал, потому что нахрена это нужно, если гораздо проще и правильнее тупо не пользоваться поделками этих идиотов.

этот прекрасный проект отправит страницу памяти с твоим секретным ключом в своп, откуда его сможет достать кто угодно.

Любопытно. А своп что, просто так на дороге валяется, и его может взять кто угодно, достаточно всего лишь нагнуться?

не использовать телеграмм, как и любые другие социальные сети, они были созданы исключиткльно для одной цели — осинта

Все зря. Тайное всегда становится явным. А закон нарушать нельзя.

Из коробки тележка ничего не шифрует, а шлёт плейнтекстом (возможно шифрует тем ключом что есть у Пашки). Сквозным шифрованием шифруется только секретный чат и только на мобильных устройствах.

А чем блокировка поможет? Банковское приложение с ним понятно, там пароль нужен и я с этим не спорю. А если через смс доступ восстанавливать, то челики просто симку переткнут и «восстановят доступ». ЗЫ СМС-ки (в том числе от банка с реквизитами) почитают через сайт оператора связи скорее всего.