• unk

Шифрование и мессенджеры.

0. Предисловие


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

Любого здравомыслящего человека в наши дни беспокоят 3 простых вопроса: 1️⃣❓ возможен ли безопасный канал удаленной связи в принципе, хотя бы теоретически? [и если да]

2️⃣❓ существует ли сегодня в природе практическая реализация такого канала? [и если да]

3️⃣❓ как я могу этим пользоваться?

*Да, сразу оговорюсь: мы не обсуждаем gsm (звонки, смс, ммс) в принципе, ни в каком виде - это не может быть безопасно от слова абсолютно

gsm - все равно что орать друг другу из одного конца вагона в другой в час пик - вот примерно такой уровень конфиденциальности, поэтому сразу оставим эту тему

✔️Безопасный канал связи может быть реализован только через интернет - зафиксируем

**И да, оговорюсь еще, что ни один даже самый-самый безопасный и защищенный мессенджер сам по себе не может обеспечить безопасную коммуникацию, только - безопасный канал, и то.. еще дай бог справится

Безопасность коммуникаций - тема куда более обширная, там и анонимность, и сеть, и сам узел, и банальная гигиена, итд итп

protect ur communications, но вы уже, должно быть, в курсе😘


Содержание (ч.1)

0. Предисловие

1. Концептуально 1.1. p2p 1.2. server-based 1.3. рейтинг, методология, участники

2. Что и как считать? 2.1. владелец/разработчик 2.2. e2e-шифрование 2.2.1. симметрично-асимметрично 2.2.2. три проблемы шифрования 2.2.3. алгоритмы/протоколы

Часть 2

1. Концептуально


1️⃣❓ возможен ли безопасный канал удаленной связи? В ответ на этот вопрос, как правило, начинают сыпаться малопонятные термины: e2e, p2p, decentralized/federated, ключи/сертификаты, aes, дифи-хелман какой-то..

Пойдем от простого к сложному, и для начала введем в наше уравнение:

a и b - это два абонента, которые хотят безопасно пообщаться друг с другом

И термин:

пакеты - это любое содержание интернет общения (и не только общения), текст - это пакеты, звонки - это пакеты, файлы - это пакеты, пакеты данных

Ну и для разминки рассмотрим сколь простую, столь же и утопичную концепцию - p2p. Это красивая идея, о ней написано много замечательных слов и еще больше - лозунгов, она даже имеет несколько практических отражений в реальности.. Но суровая правда жизни разбивает всю эту красоту об (1) убогость исполнения и (2) фатальную несовместимость тех.условий с окружающей действительностью🤷‍♂️ Чем-то напоминает коммунизм, не правда ли?

1.1. p2p


Концепция p2p гласит:

безопасным может быть лишь тот канал, который установлен непосредственно между a и b, т.е. peer-to-peer - p2p

То есть, переводя на технический язык: посередине не должно быть промежуточного (маршрутизирующего) сервера, который бы принимал пакеты от a и направлял бы их b (и наоборот b ->a).

Пиры (a и b) должны неким образом сами находить друг друга в интернете и сами маршрутизировать друг другу пакеты. И если говорить кратко - это тупо не работает, сообщения не доходят/доходят невовремя; звонки - 9ый круг ада: сбои, вылеты; клиенты - говно, недопилено, недоделано, лагает, крашится и прочие прелести безопасного общения.

Юзабилити, хотя бы базовое, хотя бы какое-нибудь - оно же должно присутствовать, нет? Иначе зачем этим вообще пользоваться? Юзабилити не может дать много баллов, даже если оно очень хорошее, мы все-таки оцениваем безопасность. Но если его нет - это жирный минус, это фактическая неработоспособность, техническое поражение.

Не было еще ни одного по-настоящему рабочего p2p мессенджера для телефона, и вряд ли он когда-либо появится.

Здесь речь даже не о безопасности канала, а о его принципиальной несостоятельности: ❌Нужен либо какой-то другой интернет, где каждому девайсу присвоится свой ip-адрес, однажды и навсегда (охуенно безопасно, правда?) ❌Либо чтобы каждый пользователь соответствующего p2p протокола носил с собой по небольшому маршрутизирующему серверу, по крайней мере часть из которых должна иметь опять же статический ip


так не бывает


Проблема p2p даже не столько в тотальной дисфункции, сколько в абсолютной бессмысленности. Даже если по дороге от a к b не будет сервера мессенджера (=железки), то хуева туча других железок все равно ж никуда не деваются: от базовой станции/wifi-роутера, через сервера опсоса/провайдера, к распределительным коммутаторам и маршрутизаторам, по кабелям, по дата-центрам, из страны в страну - это и правда можно назвать p2p? Разве что через briar, стоя на одной площади по wf/bt.. ну тогда зачем вам вообще интернет и, собственно, телефон? Вы же рядом, подойдите, пообщайтесь.

Прежде чем перейти к чему-то более реалистичному, оговорюсь, что существует даже p2p без сети. Сейчас заострять уже не будем, вот тут подробнее, если кому интересно.

Также, предчувствуя недовольство идейных, в частности указание на реально существующее воплощение p2p - briar, сходу направляю таковых изучать матчасть: начать можно отсюда, либо же сразу перейти к контрольному в голову: briar - не то что НЕ p2p, там даже сообщения не шифруются, идейные вы мои.

На этом оставим сию простую, красивую, чудесную, но абсолютно мертворожденную идею и проследуем далее - в реальность.


1.2. server-based


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

📍аптайм - (термин условный и не совсем верный строго говоря, но будем пользоваться им) т.е. доставка вовремя, т.е. a отправил и в течение 5-10 секунд b получил - если нет сервера, то как они найдут друг друга в моменте?

📍звонки - если нет аптайма, то как оповестить b о том, что a звонит ЗДЕСЬ И СЕЙЧАС?

📍хранение - если нет сервера, то где хранить пакеты, которые сейчас не могут быть доставлены, т.к. b не в сети?

следовательно,

📍файлы (фото/видео/документы/музыка) - вероятность успешной доставки стремится к нулю, собственно, как и отправки😁

Сервер посередине нужен, это удобно, это быстро, это практично, это реально


капитализм, детка


1.3. рейтинг, методология, участники


В любом случае, вовсе не факт отсутствия (или наоборот - наличия) сервера посередине обуславливает безопасность канала связи. Это как с огнестрельным оружием: это безопасно? или опасно? Какая сразу появляется вариативность, правда?🙂 смотря у кого в руках/или в сейфе лежит, смотря на кого направлено, заряжено/нет, состояние, калибр, тип боеприпаса, дистанция, сноровка, доступность цели, итд итп

Также и с безопасностью канала связи - это куда более сложносочиненная сентенция, нежели банальная железка-посередине. Чтобы ответить на вопрос "безопасно или нет?" придется учесть и сопоставить друг с другом целый ряд факторов, важнейшими из которых являются e2e-шифрование и открытость кода.

Мы тут в редакции такое усилие произвели, учли-сопоставили: собрали объективные и открытые данные, которые предоставили (или не предоставили) о себе #messengers, проанализировали их, структурировали, разнесли по параметрам, оценили каждый параметр в числовом выражении (баллы), в конечном итоге, посчитав итоговый балл для каждого участника, получили некий рейтинг. Он весьма условный, конечно, весьма субъективный по части баллов, например. Но в то же время не лишен своей стройной логики, а главное - матчасти.

Редакция в рамках настоящего исследования в первую очередь ставит перед собой задачу аккумулировать и структурировать объективные данные, разобрать механику процессов и установить причинно-следственные связи.

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


Итак, дамы и господа, встречайте участников нашего забега (A-Z):

1. briar 2. confide 3. corpchat 4. deltachat 5. dstalk 6. jabber(xmpp)+otr 7. riot(matrix) 8. safeswiss 9. safeum 10. session 11. signal 12. telegram 13. threema 14. tox 15. twinme 16. uaround 17. vipole 18. whatsapp 19. wickr 20. wire 21. zangi


Участники подобраны по заявкам подписчиков, а также - на усмотрение редакции. Кто-то наверняка не увидел здесь своего фаворита, но изучив наш рейтинг, поняв механику процессов и основные принципы, сможет легко сам(-а) оценить любого претендента, и скорее всего, по опыту редакции, оценка будет удручающая в лучшем случае.. увы, к сожалению🤷‍♂️

Хотя мы всегда готовы признать свою ошибку/недосмотр, если будут представлены объективные данные - будем даже рады.

Но хватит прелюдий, перейдем к мякотке

2. Что и как считать?


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

Пока же просто поймем из чего состоит безопасный канал в принципе:

  1. владелец/разработчик - т.е. кто владеет/управляет сервером, и/или пишет (кодит) приложения/серверную часть (далее - с.ч.)

  2. е2е-шифрование - пожалуй самый сложный, обширный и запутанный параметр, вещь в себе, но в то же время - самый важный. Вкратце: е2е должно обеспечить неприступность пакетов по дороге от a до b и обратно, т.е. из-конца-в-конец, end-to-end, e2e, сколько бы железок между ними не находилось

  3. opensource - т.е. исходный код открыт для всех и каждого. Причем нас интересует код и приложения (клиента), и с.ч., это сдвоенный параметр. Мы не оцениваем сам код, достаточно хотя бы просто: открыт он или нет, поверьте, это уже достижение

  4. базовый функционал - т.е. (1)текст, (2)файлы, (3)звонки, можно ли этим безопасно пользоваться, если оно вообще присутствует

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

  6. всякие фишечки (по безопасности) - т.е. запрет скринов, исчезания, таймеры, хуяймеры и прочее баловство. Дорого не стоит, но ладно уж, отметим

  7. юзабилити - это вообще работает? сообщения приходят? звонки прорываются?

Вот такие базовые параметры, по мнению редакции, следует рассматривать, если нас интересует безопасный мессенджер

2.1. владелец/разработчик


Ранее мы выяснили, что сервер нужен в любом случае. Но какой сервер? Чей? Что он должен делать? Как он это должен делать?

Но прежде чем перейти к совсем техническим аспектам, остановимся еще на одном простом и понятном, приземленном моменте:

чей сервер?

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

Поэтому, владелец/разработчик - один из параметров в нашем рейтинге, рассмотрим какие тут могут быть варианты:

🟢 decentralized/federated - это самое лучшее, что может предложить нам мир на сегодня, это когда мы можем собрать себе свой промежуточный сервер, и сами все контролировать. Что для этого нужно?

❗️Ну, во-первых с.ч. должна быть в открытом доступе - opensource. Но одного только opensource'a с.ч., по скромному мнению редакции, недостаточно для того, чтобы получить положительный балл по параметру владелец/разработчик. Opensource - это еще не true decentralized/federated

Например И у ваера, и у сигнала с.ч. лежит в открытом доступе - бери, собирай себе свой ваер/сигнал. Но красивая картинка упирается в суровую реальность: это совсем не так просто, как звучит.

Чтобы собрать "свой ваер" только на железо в мес нужно $200-250 (3 мощных сервака, по 6 виртуалок🙈в каждом). Полагаю, с сигналом примерно такая же ситуация, к тому же "свой сигнал" не поддерживает звонки ни в каком виде. Поэтому это НЕ тру-децентрализация, а так - красивая картинка, морковку привязали, в реальности нет этого - никто не сидит в своем сигнале/ваере.

Что же такое тру-децентрализация, спросите вы? 📌Жаба (jabber+otr) она смело получает свой заслуженный балл по этой дисциплине. Ее легко и быстро можно собрать на самой захудалой vps'ке и получить все возможные преимущества по безопасности, предусмотренные протоколом Тупо сравните в деньгах: Мы берем всего 15к за поднятие и настройку жабы, + всякие плюшки по анонимности и защите, а сам сервак - ну $40-60/год (против $200/мес у вари и это - только железо, сколько будут стоить человеко-часы - поднять и обслуживать - даже считать не возьмусь)

🔜Также, есть еще один претендент на получение положительного🟢балла по параметру владелец/разработчик именно за тру-децентрализацию И это - riot Выглядит очень перспективно и многообещающе, вообще в целом, не только из-за децентарала, но и поговаривают, что собрать несложно.. Ну мы пока это сами не проверяли, поэтому балл пока не дадим, но возможно дадим позже, наш рейтинг ведь - не путин, можно и обновлять по мере развития событий😁

Думаю, в целом по децентрализации понятно:

если мы легко и недорого можем собрать себе "свой что-то" - это положительный балл по параметру владелец/разработчик

И такой балл пока только у жабы (riot догоняет)

Но по параметру владелец/разработчик есть и другой вариант получить положительный балл:

🟢[только не смейтесь] p2p да, это нежизнеспособно в целом (по крайней мере пока), но это все еще очень и очень безопасно конкретно по этому аспекту, грубо говоря:

отправлять пакеты p2p уж никак не опаснее, чем через свой сервер

поэтому все p2p получает точно такой же положительный балл по этому параметру, как и жаба

Дальше по параметру владелец/разработчик у нас будет еще:

⚪️нейтральная оценка сюда попали те, чья с.ч. - только их, никаких opensource'ов, что там происходит - знают только они, но при этом

ничего плохого вот так на поверхности о них не лежит

т.е. грубо говоря - хз, может нормальные люди, а может уебки замусоренные - нейтральная оценка, в общем.

Также сюда попал и ваер, потому что вроде бы и можно "свой ваер", но я что-то живого доказательства пока не видел, но и плохого по делу за них не слыхал (видео треугольника - это пародия на анализ, не рекомендовал бы на него ссылаться)

Вы спросите, а как же телеграм/сигнал? Они же во многом похожи вроде бы. А для тг/сг и им подобных у нас тоже есть соответствующая категория:

🔴проблемы

сюда, помимо указанных тг/сг попали также вотсап с его фейсбуком, по результатам всенародного голосования - briar, ну и так скопом - сразу все ру-снг

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

ИТОГО владелец/разработчик 🟢tru-decentral/p2p️хз 🔴все плохо

Считаю, что этот сложный и неоднозначный параметр оценен весьма справедливо по сути: (1🟢) доверять можно только себе, (2⚪) но и обвинять огульно никого не стоит, (3🔴) ну а если уж кто зашкварился - пусть кушает


2.2. e2e-шифрование


Как уже сказано выше, шифрование - самый важный аспект при оценке безопасности каналов связи. Но и самый сложный, так что приготовьтесь, мы взлетаем.

Итак, наши пакеты снуют по интернету туда-сюда, и даже если не будет сервера-посередине (p2p), то там все равно еще очень много чего будет, через что эти пакеты пройдут и, не исключено, останутся навсегда (привет сорм-коробкам)

Нам в любом случае не избежать засвета пакетов по дороге от a к b

❓Соответственно, что надо сделать с пакетами? ✅Правильно, зашифровать

Из малопонятных терминов сюда относятся: e2e, aes, rsa, cha-cha, sha, hmac и, конечно же тот самый загадочный дифи-хелман (dh); также сюда относятся цифры, кратные восьми: 128, 256, 512, 1024, 2048, 4096, их обычно прилепляют справа к аббревиатурам, указанным выше. Что это все значит в простом человеческом понимании?

Если пакеты, которые отправит a, будут зашифрованы таким образом, что расшифровать их сможет только b, то это позволит им обоим пренебречь сервером мессенджера (а равно любой другой железкой-посередине), т.к. весь путь пакеты пройдут в зашифрованном (т.е. нечитаемом) виде

Еще проще:

вместо наших сообщений/файлов/голоса - 08y977WD83563d3gd9736d8736dgd, вот что-то такое, примерно
и так на всех узлах (серверах) по дороге от a к b

Такое шифрование называется сквозным, или оконченным, или е2е. Строго говоря, любое шифрование, если разговор идет о мессенджерах, должно быть только и исключительно е2е, иначе какая там безопасность. Но и здесь не все однозначно, впрочем вы уже должны были бы привыкнуть😁 е2е - вообще очень размытый термин.. точнее термин-то нормальный, а вот применяют его куда не попадя, потому что это не какая-то конкретная технология, а набор технологий + практик. Ну а где практика, там человек, а значит и дьявол опять в деталях копошится где-то рядышком.

Ну и перед тем как перейти уже к этим деталям, усвоим еще парочку базовых постулатов:

№1 шифрование ВСЕГДА происходит (совершается) по АЛГОРИТМУ и/или ПРОТОКОЛУ
№2 шифрование ВСЕГДА подразумевает под собой КЛЮЧ(-И)

Разжуем: АЛГОРИТМ/ПРОТОКОЛ - это условная формула, например

s+k=p

где: s - наше содержание (текст/файл/звонок) k - КЛЮЧ шифрования p - финальный пакет, представляющий из себя наш текст/файл/звонок, зашифрованный ключом

Так вот даже из этой нехитрой математики наглядно явствует: безопасно - это когда в мир мы отпускаем только p - финальный пакет, потому как если этот коварный мир получит еще и k - КЛЮЧ, то легко расковыряет наше sодержание обратно:

p-k=s

Объяснение схематичное, в реальности формулы посложнее будут, конечно, но суть, надеюсь, уловили.


2.2.1. симметрично-асимметрично


Но какими бы сложными ни были формулы, т.е. алгоритмы/протоколы шифрования, их общее количество и вариативность - весьма скромны. А базовых принципов - так и всего два: симметричное и асимметричное.

🔄Симметричное шифрование Если для шифрования и дешифрования пакетов используется один и тот же ключ🔑 - это называется симметричным шифрованием. Т.е. у a и b есть один и тот же, одинаковый🔑ключ, с помощью которого они шифруют свои пакеты и дешифруют пакеты друг друга

↪️↩️Асимметричное шифрование Если для шифрования и дешифрования пакетов используется два разных ключа🗝🔑- это называется асимметричным шифрованием. Т.е. у b есть пара связанных друг с другом ключей: открытый🗝 и закрытый🔑

Открытый🗝 он передает a в любом виде: хоть в городской газете печатает, а вот закрытый🔑 - оставляет себе и никому не показывает

Теперь a берет открытый ключ b, шифрует с помощью него исходящий пакет, после чего b дешифрует этот пакет с помощью своего закрытого ключа

Еще можно сказать так:

⤴️чтобы отправить кому-то зашифрованный пакет - нам надо узнать открытый ключ персонально этого кого-то

но

⤵️чтобы расшифровать любой входящий пакет, от кого бы он ни был - нам нужен только наш персональный закрытый ключ


отличная иллюстрация, скажем спасибо автору (не мне)


И на первый взгляд очевидная проблема симметричного🔄шифрования - сам ключ🔑. Собственно, ключ - это же тоже пакет, текстовый файл, а его же надо как-то передать и a, и b (распределить), чтобы они уже шифровали/дешифровали с помощью него дальнейшие пакеты. А как это сделать-то? В голом виде же не пошлешь, вспоминаем формулу p-k=s, подарим ключ - подарим все. Дилемма получается..

Как бы асимметричное↪️↩️шифрование - ответ на эту дилемму (весьма условно и весьма условный), где свой открытый (публичный) ключ можно распространять по каким угодно дырявым каналам, т.к. с помощью него можно только ЗАшифровать пакет, а вот для РАСшифровки потребуется уже закрытый (приватный) ключ, который передавать никуда не требуется.

Казалось бы, идеальная схема

Кстати, по такому же принципу асимметричного шифрования работают и электронные цифровые подписи - ЭЦП (ну большая часть)По такому же, только наоборот - мы подписываем (шифруем) своим🔑, а любой человек может проверить что подпись именно наша с помощью нашего же🗝 (расшифровать и убедиться)


2.2.2. три проблемы шифрования


1️⃣❗️Но проблема распределения ключей лишь на первый взгляд касается только и исключительно симметричного шифрования, и лишь на первый взгляд решается с помощью асимметричного. И это лишь та проблема, которая лежит на поверхности.

2️⃣❗️Существует еще угроза MITM (man-in-the-middle, человек-посередине). Т.е. на одной из тех самых железок, через которые проходят пакеты между a и b, может сидеть плохой человек-посередине, который будет всячески перехватывать и подменять пакеты обеим сторонам, в частности подменять ключи, выступать в роли b для a и в роли a для b, расшифровывая таким образом весь трафик посередине, на себе - фейковом собеседнике для обеих сторон.

3️⃣❗️И существует еще одна проблемка с шифрованием - правдоподобное отрицание, также это называют - отрицаемое шифрование. Смысл в том, что когда и если будут спалены те или иные ключи, то у a и b должна остаться правдоподобная (т.е. обратное - недоказуемо) возможность сказать "а это не мое/не мне/не от меня" и в отношении самих ключей, и в отношении содержания. В данном случае, конечно, еще большой вопрос к самому содержанию: если там окажется наш паспорт, к примеру, то будет довольно сложно правдоподобно отрицать. Но и все же, несмотря на кажущуюся человеческую природу этой угрозы, на самом деле, сегодня - она вполне техническая.

Вышеуказанные 3 проблемы в действительности представляют из себя один большой взаимосвязанный клубок, например:

2️⃣❗️ человек-посередине перехватил ключи, вследствие их 1️⃣❗️ неправильного распределения, после чего предъявил a и b переписку, которую 3️⃣❗️ невозможно отрицать, т.к. установлена цепочка принадлежности: человек-ключ-пакет

Зафиксировали


2.2.3. алгоритмы/протоколы


Теперь давайте развернем это все на практике, и немного - на исторической перспективе. Но перед этим до конца проясним терминологию: алгоритм шифрования и протокол шифрования - это одно и то же или разные вещи?

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

Протокол же - это про как, куда, кому, сколько, когда, как часто - т.е. окружение алгоритма.

Конечно, оговоримся, что и эта терминология, и это разделение - опять же весьма условны, кто-то называет свои протоколы алгоритмами, и наоборот, но мы будем для удобства пользоваться такими определениями:

алгоритм - математическая суть
протокол - применение/окружение/реализация алгоритма

Этот мессенджер безопасен? (Часть 2)


Содержание (ч.2) Часть 1 (...2.2.3. алгоритмы/протоколы) 2.2.4. базовая асимметрия 2.2.4.1. RSA (1977) 2.2.4.2. PGP/OpenPGP (1991/1997) 2.2.4.3. SSL/TLS (1995/1999) 2.2.5. базовая симметрия 2.2.5.1. AES (1998), DES (1977) 2.2.5.2. Salsa/ChaCha (2005/2008) 2.2.6. промежуточный итог 2.2.7. решаем 3 проблемы шифрования 2.2.7.1. распределяем ключи DH (1976), ECDH (2006) 2.2.7.2. нейтрализуем человека-посередине SHA (1995), Poly1305 (2005) Часть 3 2.2.4. базовая асимметрия

Ну что, здравствуй, наконец, реальность🤝 Начнем с асимметричных↪️🗝🔑↩️вариантов: 2.2.4.1. RSA (1977)

И начать разговор об асимметрии можно только с rsa - прародитель, ветеран, бывалый, заслуженный, действующий резерв. rsa - самый базовый алгоритм асимметричного шифрования rsa лежит в основе и/или составе очень и очень многих актуальных протоколов шифрования, фактически - активно используется аж по сей день. И базово - это надежный алгоритм шифрования, т.е. один условный перехваченный пакет без ключа расшифрован не будет. Но это один и условный и без ключа (3 проблемы). Конечно, от rsa чудес ждать и не стоило, это всего лишь алгоритм, но заслуженную дань уважения отдаем в любом случае. Кроме того, стоит еще отметить, что rsa - это очень медленно (все-таки '77 год) Собственно, поэтому он почти никогда не используется (в рамках протоколов) для шифрования самого sодержания, даже текста (не говоря уже о файлах/звонках), а применяется, как правило, для шифрования чего-нибудь поменьше: ключей/сертов/метадаты/хендшейков/подписей/итд, т.е. того, что сопровождает основные (большие) пакеты в их нелегком пути между a и b. Почти никогда, за исключением разве что: 2.2.4.2. PGP/OpenPGP (1991/1997)

pgp - это классический асимметричный е2е-протокол, вот прям для двух собеседников - людей, создавался для общения через email вообще (какие уж там #мессенджеры в '91). Изначально pgp НЕ был opensource, а был - proprietary, т.е. проприетарным программным продуктом (а это был не просто протокол, а прям продукт - набор библиотек и прочего софта для непосредственного использования). Проприетарный - значит коммерческий, закрытый от публики, следовательно (самое важное) - И КОД ЗАКРЫТ. Но потом кто-то удачно все это дело спиздил, перелопатил как-то там слегка, адаптировал и создал уже свой протокол+программный продукт (почти близнец), назвав это - openpgp, подразумевая под этим полнейший opensource. Ну чтож, спасибо этому крадуну, дал нам хоть пищу для обсуждений, не говоря уже обо всем остальном - т.е. ценнейшем вкладе в человеческое наследие, без шуток. Суды, кстати, идут до сих(!!!)пор. Вот же сутяжники эти pgp-шники дешевые, даже винклвосы - и те уже давно схавались😁 Воистину - жадность фраера погубит. Оставим эту драматургию и перейдем к технике: (open)pgp - основан на rsa т.е. sодержание (в данном случае сугубо текст) шифруется rsa-алгоритмом. Реализация асимметрии↪️↩️ - в лоб: a и b создали себе по паре 🗝🔑 обменялись 🗝 с помощью 🗝 друг друга шифруют исходящие пакеты с помощью личных🔑- дешифруют входящие И базово, благодаря rsa - это надежно. Но это базово ("один, условный и без ключа"). А в реальности (open)pgp сталкивается с проблемкой.. а точнее даже - с тремя: 2️⃣❗️человек-посередине будет собирать и копить пакеты уже точно зная, что они наши - ключ то 🗝ПУБЛИЧНЫЙ, к тому же ПОСТОЯННЫЙ (1️⃣❗распределение ключей). В один прекрасный день он соберет достаточно, после чего отправит к нам группу специалистов по крипто-ректальному-термо-анализу, получит наш 🔑 и расшифрует накопленные пакеты в 100% привязке к нашей грустной харе - какое уж тут 3️⃣❗️правдоподобное отрицание Наглядный факт: в деле "сети", фигуранты которого активно пользовались pgp, даже не дошло до этого этапа - до необходимости правдоподобного отрицания. Не пришлось, обошлись без пакетов, ключей и прочей хуеты. Сугубо крипто-ректальный метод. НО фсб-посередине достоверно точно установила цепочку принадлежности: пакет-ключ-человек


Резюмируя по (open)pgp: ✔️надежно зашифрует пакеты, но и только ❗️постоянный, известный всем ключ - жесткое палево: мусора скопят пакеты, выпытают ключ, подошьют факты в дело

2.2.4.3. SSL/TLS (1995/1999)

Протокол tls - есть развитие (продолжение, дочка) протокола ssl, и строго технически говоря: все это е2е, т.к. обеспечивает шифрование из-конца-в-конец, но есть нюанс: в данном случаем одним из концов будет сервер, потому что ssl/tls - это протокол шифрования клиент-сервер, тот самый, который дает s, в конце https, например. ❗️️Поэтому надо понимать: да, tls/ssl позволяет безопасно общаться с сервером, но на самом сервере - все sодержание в открытом виде, поэтому для a и b - это НЕ безопасно, НЕ е2е. Реализация ↪️↩️ в данном случае частичная: асимметрично🗝🔑 (rsa) шифруется только одноразовый (на одну сессию) симметричный🔑 ключ а уже с помощью него шифруются все дальнейшие пакеты В целом, по факту ssl/tls - это https, т.е. - шифрование между посетителем и сайтом.. ну не знаю стоит ли тут вообще распинаться.. ладно, уговорили😁 ❗️помимо того, что это бессмысленно изначально: за каждым сайтом все равно стоит своя сорм-коробка, а то и несколько ❗️помимо того, что сам протокол насквозь дырявый и критические уязвимости находят по сей день (ssl1->ssl2->ssl3->tls1->tls1.1/1.2/1.3) ❗️помимо того, что человеку-посередине нужен лишь БЕСПЛАТНЫЙ ssl-strip (kali linux) для полной дешифровки пакетов Помимо всего этого, есть у ssl/tls одна фатальная, корневая, нерешаемая проблема - сертификаты и сертифицирующие центры. Смысл в следующем: ssl/tls должен не только зашифровать пакеты, но и удостоверить нас в том, что пакеты летят между нами и конкретным сайтом, оригинальным сайтом. Мы должны как-то точно узнать, что вводим свои логин/пароль именно на сайте своего банка, а не на фишинговом сайте с похожим доменом, например. Обеспечить для нас это знание и должен некий сертифицирующий центр, путем выпуска сертификата для открытого ключа нашего банка. Т.е. некий центр проверяет и удостоверяет, что: банк - это банк домен принадлежит банку открытый ключ принадлежит банку и все тут четко и законно Это типа решает проблему распределения открытых ключей: такой нотариус в интернете, авторитетная персона, которой мы должны почему-то поверить. Ну уже сами чуете куда идет, да? Проблема с сертификатами и их центрами (а следовательно и с ssl/tls) в том, что они не могут выполнить ни одной поставленной задачи, не работают ни в одном направлении: ➡️это не может защитить нас от фишинга: вспоминаем клаудфлер и то, как легко он раздает свои серты (абсолютно такие же, законные, ничем не хуже других, в адресной строке все зелененькое и подтвержденное, как у настоящего банка) ботоводам, кардерам и фишерам ⬅️это не может обеспечить нам хоть мало-мальской сохранности данных: мусора приходят в сертифицирующий центр, выпускает себе дубль ключа/свой ключ, и дальше разгоняются как хотят - возможностей перехвата/дешифровки/разъеба не счесть Резюмируя по ssl/tls: ❗️несмотря на https в адресной строке, все, что мы оставили в интернете - мы оставили В ОТКРЫТОМ ВИДЕ НА СТОЛЕ У МУСОРА, оставили НЕСКОЛЬКО РАЗ НАВСЕГДА ✔️это безопасно только когда мы - владелец сервера и центра, и хорошо при этом понимаем что, как и зачем делаем, и только как для владельца сервера; с точки зрения обычного юзера этот протокол не дает почти никакой безопасности - фиговый листок 2.2.5. базовая симметрия

Что касается полноценных, но при этом сугубо симметричных🔄протоколов (по аналогии с pgp и ↪️↩️), то их просто не существует в природе, т.к. распределение общего секретного🔑 невозможно организовать симметрично, придется изъебываться, получится уже не голая симметрия. Но зато, существуют прекрасные симметричные алгоритмы, которые делают читаемое - 100%-но нечитаемым. Быстро, с гарантией и одним 🔑 на выходе, ну а дальше ебитесь с ним как хотите 2.2.5.1. AES (1998), DES (1977)

И если ↪️↩️ начинается с rsa, то 🔄 - с aes. Можно сказать, что aes пришел на смену алгоритму des, хотя напрямую ему и не наследует. aes - это максимально надежно, это не ломается, это широко применяется не только в рамках е2е, но и для локального (офлайн) шифрования, например диска или флешки Говоря об офлайн шифровании у aes, конечно, есть конкуренты, всякие рыбки и кузнечики, одни из которых вроде бы не так плохи, но уступают в скорости, другие - имеют сертификацию фсб (как вам такой серт-центр?😁). Но в целом, нет ни одной разумной причины предпочесть aes'у другой алгоритм по части офлайна. Что же касается е2е (т.е. онлайн шифрования), то тут все-таки стоит отметить достойного конкурента, а точнее даже - целое семейство: 2.2.5.2. Salsa/ChaCha (2005/2008)

Данное семейство симметричных🔄алгоритмов отличается от предыдущего (des/aes/и пр) самим алгоритмом, т.е. самим принципом шифрования: aes (des) - это блочное шифрование, т.е. sодержание шифруется блоками, кусками, т.е. отдельными сообщениями/картинками/кусками голоса в то время как salsa/chacha - это потоковое шифрование, т.е. sодержание шифруется элементами, минимальными неделимыми частицами, т.е. буквами/символами/пикселями(🤷‍♂️) Salsa20 - родоначальник семейства, сегодня используется нечасто, надо полагать из-за наличия более быстрых (оптимизированных) модификаций - xSalsa20, ChaCha20, xChaCha20, при этом ChaCha-ответвление еще и чуть более безопасное (усложненное). Все это семейство рождено и модернизируется одним персонажем (ну или он просто фронтмен, хз) - Даниэлем Джулиусом Бернште(а)йном, низкий ему поклон, т.к. алгоритмы походу путевые, и именно для онлайна (е2е), судите сами: ✅пока никто не нашел ни одной дыры даже в самой первой sals'е, а активистов в этой сфере хватает, благо алгоритмы-то все - opensource (иначе и заикаться бы не стал) ✅потоковое существенно быстрее блочного (хотя aes все еще имеет запас скорости к сегодняшним реалиям, скажем так, но все-таки мир быстро меняется)потоковому не так страшны обрывы связи (условно: потеряется не целое сообщение, а только 1 буква) ✅все больше и больше разработчиков/систем/протоколов переходят на/добавляют себе чачу-сальсу (в основном ChaCh'y20 почему-то, но причины уже точно за рамками данного исследования) 2.2.6. промежуточный итог

Подведем небольшой итог. По↪️↩️асимметрии: ❗️распределение ключей - все еще проблема, т.к. открытый ключ - палит всю хату, лишая нас возможности правдоподобно отрицать ❗️любое клиент-сервер шифрование (tls) предполагает расшифровку пакетов на сервере и не является для нас сколько-нибудь надежным, за исключением случаев, когда мы сами владеем/управляем тем сервером, или доверяем его владельцу/админу ❗️сертифицирующие центры - галимые нотариусы, а их сертификаты - галимые доверенности, и уж точно эта концепция никак не помогает решить ни проблему распределения ключей, ни проблему человека-посередине: человек-посередине защищает нас от человека-посередине😂, бля это ж надо было додуматься ❗️это медленно, поэтому практически никогда (за искл. pgp) не используется для шифровки sодержания ✅но это все еще предельно надежно (rsa) и порой удобно, поэтому широко используется в составе современных е2е-протоколов для шифрования небольших пакетов, сопровождающих sодержание (ключи/серты/чексуммы/итд) Что же касается 🔄симметрии: ❗️ни ключи, ни середина, ни отрицание (3 проблемы) и здесь сами себя не защитят и не обеспечат, тем более что голая симметрия - это только алгоритмы, т.е. сугубо математика ✅но зато это предельно надежно ✅и кроме того, еще и довольно шустро, поэтому симметрия (aes/chacha) используется в рамках e2e-протоколов уже как раз для шифровки sодержания Едем дальше 2.2.7. решаем 3 проблемы шифрования

Итак, способ надежно зашифровать sодержание (алгоритм) имеется, и даже несколько. Теперь. Чтобы из надежного алгоритма сделать надежный е2е-протокол нам необходимо решить все те же 3 насущные проблемы: 1️⃣❗️распределить ключи: будь они открытые или закрытые, постоянные или одноразовые - их надо распределить между a и b таким образом, чтоб ни одна 2️⃣❗️блядь-посередине не смогла получить доступ ни к ключам (любым🗝🔑), ни к открытым пакетам тем более, а также желательно не дать ей доступа к открытой метадате/чексуммам/сертам и прочей мелочи, которая сопровождает наши пакеты-с-sодержанием. И все это для того, чтобы оставить себе возможность 3️⃣❗️правдоподобно отрицать причастность ко всем этим пакетам/ключам/метадате/тяжкимпреступлениям И, конечно, мы далеко не первые, кто задумался обо всем об этом. 2.2.7.1. распределяем ключи DH (1976), ECDH (2006)

В частности некто Диффи и его кентаврик Хеллман задумались о 1️⃣❗️распределении ключей довольно давно, и уже в 1976 представили миру свой протокол Дифи-Хеллмана (dh) - протокол обмена секретным 🔑 между a и b, которому не страшен никто-посередине, а ключ гарантировано достается только a и b, т.к. НЕ ПЕРЕДАЕТСЯ ПО СЕТИ Технически выглядит примерно так: 1. для a и b создается (локально, в телефоне) по 1 открытому параметру - Oa и Ob, и по 1 закрытому - Za и Zb 2. a берет открытый параметр b - Ob (берет по сети, т.е. в открытую для всех) 2.1. добавляет к нему оба своих параметра - Oa и Za 2.2. локально, у себя в телефоне диффи-хеллмит (*dh) это все между собой 2.3. в результате получает некое значение, назовем его - dh-параметр 2.4. [условная] формула для a: (Ob+Oa+Za)*dh = dhOa 3. b в этот момент производит аналогичную (зеркальную) операцию, получая уже свой dh-параметр: 3.1. (Oa+Ob+Zb)*dh = dhOb 4. a и b обмениваются dh-параметрами друг друга по сети, в открытую: dhOa -> b, dhOb -> a 4.1. и при этом не боятся, что из dhO кто-то сможет размотать обратно их Z, т.к. придется перебрать пару триллионов вариантов и наконец 5. a и b повторно диффи-хелмят dhO друг друга со своим Z, получая таким образом общий одинаковый🔑ключ, ЛОКАЛЬНО, У СЕБЯ В ТЕЛЕФОНЕ: 5.1. (dhOb+Za)*dh = 🔑 = (dhOa+Zb)*dh Скажу вам по секрету: это пиздец как круто, а этих двух пассажиров (dh) можно смело причислять к лику святых, человечество им весьма обязано, но, как обычно, даже не в курсе🤦‍♂️ По большому счету, аналогов у этого не существует аж по сей день! Справедливости ради надо отметить уже упомянутого ранее Бернште(а)йна, который в '06 году присобачил к dh какие-то там эллиптические кривые (🤷‍♂️🙈даже не спрашивайте) и назвал все это вместе - Elliptic curve Diffie–Hellman, или ecdh, или по-русски: диффи-хеллман-на-эллиптических-кривых. Смысл этого тюнинга в скорости: эллиптический диффи существенно быстрее обычного, но никаких добавок по безопасности он не дает. Консенсусное мнение специалистов: ecdh не уступает в стойкости обычному dh Хотя существует и иная точка зрения, но мы будем придерживаться консенсуса, тем более что если и уступает, то не сильно: [условно] придется перебрать не пару триллионов комбинаций, а полтора триллиона Поэтому dh и ecdh - это надежно, это не ломается, это позволяет получить общий одинаковый🔑 безопасно, т.к. он создается локально, т.е. НЕ покидает телефон ВООБЩЕ Конечно, существуют и другие протоколы распределения ключей: можно хоть tls'ом их раскидать, хоть любой другой асимметрией, опять же на эллиптические кривые ее частенько натягивают - всякие eddsa/ecdsa/ed-с-какими-то-цифрами. Но Надо понимать! Все эти способы распределения ключей - server-based. Т.е. этот самый сервер увидит/сможет увидеть наши драгоценные ключи, а значит и наши куда более драгоценные сообщения/файлы/звонки. Более того, наши драгоценные ключи будут еще и по сети гулять, что КРАТНО мультиплицирует угрозу (wifi в кафе/оператор на шлюзе/мусор на сорме). Конечно, безопасно отправить ключ по сети можно, никакой магии: шифруем его как обычное сообщение надежным e2e-протоколом, делов-то😁 Но для этого ведь надо сначала безопасно раздать ключ, и на этом порочный круг server-based-ключей замыкается. Поэтому распределение ключей - это только (ec)dh, все остальное - от лукавого и безопасным НЕ ЯВЛЯЕТСЯ И в целом эту насущную проблему можно считать решеной.. можно было бы, но как всегда есть нюанс: 2.2.7.2. нейтрализуем человека-посередине SHA (1995), Poly1305 (2005)

И тут мы опять упираемся в этого уебского 2️⃣❗️человека-посередине. Да, от него надо защищать не только основные пакеты, но и процесс распределения ключей, даже если он проходит с помощью (ec)dh. В данном случае речь не столько о прослушке (от этого должно защитить шифрование), сколько о подмене: dh-параметров/ключей и, в конечном итоге, самого sодержания, что грозит уже не просто прослушкой, а самым что ни на есть "мам, скинь 100 рублей на телефон, я человека убил". Чтобы решить проблему человека-посередине в корне, надо сделать довольно простую вещь: убедиться, что пакет/ключ/итд, который a послал b, есть именно тот самый пакет/ключ/итд, что создал и отправил именно a, а не кто-нибудь-посередине. Другими словами: нужно обеспечить целостность и аутентичность пакета/ключа/итд И с этой проблемой нам тоже повезло, потому что умные люди придумали такую штуку, как хеш-функция (mac/hmac): в отношении пакета вычисляется определенное значение, и такое значение будет уникальным для каждого уникального пакета. То есть: два одинаковых сообщения "привет", отправленных одному и тому же адресату, но с разницей в долю секунды - это уже разные пакеты, у них будут разные хеш-функции Еще проще: хеш - это отпечаток пакета, он всегда уникален Хеш вычисляется не просто из конкретного пакета с sодержанием, но и имеет корреляцию с предыдущим пакетом. Такая конструкция надежно защитит нас от этого уебка-посередине: если он в моменте вклинится и попытается что-то перехватить/подделать - у нас сразу перестанут биться хеши. Понимающие могут усомниться: хеши-то брутят (т.е. перебирают sодержание пока не совпадет). И да, это так, но лишь отчасти. ❗️Во1, успешно брутятся только слабые алгоритмы хеширования, в 1 очередь - md5, реже sha1 (1995) ❗️Во2 и в главных, успешно брутится только совсем простое sодержание, в 1 очередь - пароли (по словарю). Раньше еще кредитки (только цифры - идеально для перебора), но те времена давно минули, т.к. карточек в хешах больше не существует в природе, вымерли. В свете вышесказанного, рекомендую понимающим провести натурный эксперимент: 1. придумать пароль, которого нет в словарях, т.е.: символов 25, a-Z, 0-9, !@#$ 2. захешить его хотя бы даже md5 3. и попробовать сбрутить его любым доступным методом, коих - сотни. После нескольких месяцев безуспешных попыток, порекомендовал бы экспериментаторам поберечь себя и перейти в плоскость рассуждений: 4. увеличить пароль (п.1) в 2-100 раз (примерно так будет выглядеть наше шифрованное общение с позиции-посередине) 5. захешить это предельно надежным sha2 (в миру - sha256/512) 6. и прикинуть хуй к носу: реально это сбрутить или нет?🙂 Помимо упомянутых выше sha1, который не считается надежным (хотя это скорее про небольшие-пароли-по-словарю, в условиях е2е угроза стремится к нулю, но тем не менее) и sha2 (2012), который предельно надежен и не взламывается на существующих мощностях (если это опять же не пароль-по-словарю) существует также sha3 (2015), который еще надежнее, (и тоже бывает 256/512, кстати), но в рамках е2е-шифрования почему-то не применяется Ну и кроме того, уже легендарный Бернште(а)йн и здесь постарался и создал протокол хеширования poly1305, который, по классике, не уступает в стойкости, но зато быстрее работает. Выказываем ему очередную порцию уважения. Теперь суммируем по mitm/чел-посеред/целостность-и-аутентичность: от mitm'а нас надежно защитят протоколы sha2 и poly1305, все просто🙂 И напоследок скажем, что есть еще dtls, который тоже призван обеспечить целостность и аутентичность пакетов, но вы уже умненькие, и видите там недвусмысленное tls, а это значит от mitm'a нас будет защищать другой mitm, сразу на душе спокойствие, да? Повезло лишь, что применяется этот dtls очень узко, о чем скажем чуть позже. Этот мессенджер безопасен? (Часть 3)

Содержание (ч.3) Часть 2 (...2.2.7.2. нейтрализуем человека-посередине SHA (1995), Poly1305 (2005)) 2.2.7.3. правдоподобно отрицаем 2.2.8. циферки 2.2.9. типы данных 2.2.9.1. файлы 2.2.9.2. звонки SRTP (2004) + DTLS (2012), WebRTC (2011) 2.2.10. промежуточный итог 2 Часть 4

2.2.7.3. правдоподобно отрицаем

Ключи распределили, целостность/аутентичность подтвердили, но.. Представим: 1️⃣мусора знают, кто такие a и b 2️⃣пасут их, следовательно, пасут все пакеты 3️⃣пасут и копят 4️⃣не ломают, не брутят, не mitm'ят 5️⃣тупо складывают в свою мусорскую сорм-коробочку, лишь индексируя маршруты: a->b|b->a 6️⃣и вдруг, один день, 5 утра, сразу по двум адресам: здрааасьте, а вам тут крипто-ректалочка подъехала, не желаете? тогда может пин от телефончика? 7️⃣а вот и ключики 8️⃣где там наши пакетики? Представили? Рассуждения о "правдоподобном отрицании" в подобной ситуации выглядят комично (но только не для a и b). Поэтому данная проблема должна решаться сугубо в технической плоскости, исключив человеческий (крипто-ректальный) фактор из схемы. Как этого добиться? Да очень просто: доходим до пункта с ключиками(7️⃣), и делаем так, чтобы они были бесполезны для всего того, что накопили эти проклятые коррупционеры. Как? Одноразовые ключи: 1 пакет(текст/файл/звонок) - 1 ключ новый пакет - новый ключ новый ключ перезаписывается поверх старого нет старых ключей -> нет физической возможности расшифровать -> нечего и отрицать -> bingo 2.2.8. циферки

Итак, мы рассмотрели наиболее базовые вещи (протоколы/алгоритмы) Я не зря так подробно останавливался на aes, chacha, rsa, dh и его ec, sha, poly. Все это - базовые вещи, базовые алгоритмы/протоколы. Именно они (или их менее именитые аналоги) и лежат в основе любого современного е2е, что мы скоро наглядно и увидим. Но перед тем как уже перейти к столь разным и столь одинаковым современным протоколам е2е, надо еще упомянуть пару вводных моментов. Момент первый (совсем простой): 🔢цифры ко всем указанным ранее протоколам/алгоритмам, как правило прилепляют в конце какую-то цифру, например: aes128/rsa4096/dh2048/sha256 итд. Буквы мы теперь хорошо понимаем что означают (ну +-😁), а вот что значат эти цифры.. о чем они нам говорят? Все довольно просто: цифры - это всего-навсего физический размер (ключа/серта/хеша) Этот размер исчисляется в битах (единица создания информации) Именно поэтому эти странные цифры всегда (почти) делятся на 8 - чтобы из битов получить байты (единица хранения/пересылки информации) Т.е. aes256 - означает, что для шифрования создан и применен 256-битный ключ, rsa2048 - 2048-битные ключи (🗝🔑), и так далее по аналогии. Как это трактовать применительно к обеспечению безопасности? Можно сказать так: чем больше цифра, тем физически больше ключ/хеш (т.е. ключ rsa4096 прям ровно в 2 раза больше ключа rsa2048), тем лучше Но Так это работает строго в рамках одного протокола/алгоритма, т.е.: rsa4096 лучше чем rsa2048, а aes256 лучше чем aes128 (хотя идут споры), а sha512 лучше чем sha256 но sha512 НЕ лучше чем aes256, а rsa4096 - НЕ лучше их обоих, только лишь потому что циферки больше Это так не сравнивается, каждый протокол имеет свою реализацию, свои ключи, и размер играет роль сугубо в рамках одного конкретного протокола. Ну и кроме того Бывают и исключения в этой стройной теории о циферках (биты/байты/8): уже многократно упомянутый Бернште(а)йн, с его Salsa20/ChaCha20, poly1305 и эллиптическими кривыми (ec), где цифры вообще очень странные и разные😁🤷‍♂️. Что он там хотел своими цифрами сказать, уже рассуждать не возьмусь, но полагаю тоже что-то связанное с математикой. Как бы там ни было, на наши рассуждения это уже никак не влияет, так что будем считать по 🔢цифрам разобрались. 2.2.9. типы данных

Теперь момент второй: 🔣типы данных (типы пакетов) Условно говоря, всю нашу интернет коммуникацию можно разделить на три типа: 1. текст 2. файлы 3. звонки С текстом все понятно, это в первую очередь сообщения, а также ключи/серты/хеши - все это тоже текст. И все описанные ранее протоколы/алгоритмы в первую очередь относятся именно к тексту. Но вы скажете: текст - это пакет - это же файл, и будете правы. Но текст - это физически очень маленький файл. И этот факт самой своей природой обеспечивает скорость: маленький файл в любом случае быстро шифровать/дешифровать. 2.2.9.1. файлы

Чего не скажешь о хотя бы даже картинке, которая весит как несколько десятков, а то и сотен сообщений, соответственно делим скорость на 10-100. А теперь представьте видео. Поэтому файлы вынесены в отдельную дисциплину. И это не я так решил, а протоколы так реализованы😁 Файлы МОЖНО надежно е2е-зашифровать и отправить (a<->b), порешав даже все 3 уебищных проблемы по дороге. Не бином Ньютона, человечество уже давно на это способно. Но далеко не всегда это делается, далеко не каждый мессенджер так щепетилен с файлами в рамках своего комплексного е2е-решения. Зачастую, файлы если и шифруются, то сервер-бейсд (tls), что, как мы хорошо понимаем, никакого е2е между a и b не обеспечивает: сервер-то видит наши пип-фотки, какое ж это е2е. Поэтому Мухи отдельно, котлеты отдельно: смотрим отдельно что там с е2е по тексту и смотрим отдельно что там с е2е по файлам 2.2.9.2. звонки SRTP (2004) + DTLS (2012), WebRTC (2011)

Ну и совсем отдельно стоят звонки. И в данном случае выделяются они не размером пакетов, а типом соединения: звонок [только не смейтесь] - это всегда сугубо и исключительно p2p Да-да, всегда, когда мы звоним - мы общаемся p2p, напрямую, пакеты с данными (голосом) - летят сугубо между a и b, не заходя на центральный сервер вообще. И хотя мы уже взрослые и прекрасно понимаем, что сервер все равно должен присутствовать (чтобы сконнектить a и b, создать саму сессию), но сам звонок - всегда p2p, и это дает некие бонусы по безопасности. При этом, если по тексту/файлам мы имеем хоть какие-то вариации/адаптации/аналоги/развитие.. То, взглянув на звонки, мы в 99% случаев упремся в комбинацию: srtp+dtls Что такое srtp? [следим за руками]: 📍aes128 (*модернизированный из блочного в поточный) - само шифрование 📍dh + серверная асимметрия - распределение ключей 📍sha1 - целостность/mitm 📍одноразовые ключи (1 звонок - 1 ключ) - отрицание Лица все знакомые, но не все приятные, в частности sha первой версии явно хромает. Но главное, что смущает - сервер-based ключи, пусть и через диффи. "Надежность" сертов/центров мы уже наглядно разобрали, поэтому и назвать srtp надежным можно разве что с натяжкой. Конечно, в отличии от классического "скопить пакеты+паяльник в жопу", в данном случае мусорам придется внатуре поработать: 1️⃣захватить srtp-сервер ЗАРАНЕЕ 2️⃣понять, подчинить, видоизменить и online-контролировать распределение ключей 3️⃣засесть где-то-посередине, при том что это "где-то" может легко меняться от звонка к звонку, а инфраструктуру там развернуть придется совсем нехилую И это еще лишь пол-мусорской-беды, т.к. есть же еще "+ dtls", который при звонках как раз и используется для доп. защиты от человека-посередине. Но, к сожалению уже для нас, dtls - опять же серверный протокол. Что такое dtls? [следим за наперстками]: 📍aes128 - шифр 📍ecdh - ключи 📍sha256 - mitm 📍[и зачем-то, полагаю, как серт-центр] tls Ну что можно сказать.. dtls был бы неплох, если б не tls😁 Что можно сказать, возвращаясь к реальности/мусорам? Если мессенджеру хватило мозгов (привет владельцу/разработчику) разнести подальше друг от друга srtp- и dtls-сервера, желательно по разным юрисдикциям и собственникам (как это делаем мы со своими BespaleVPN-серверами, например), тогда мусорам ЕЩЕ придется: 1️⃣.1️⃣захватить dtls-сервер ЗАРАНЕЕ 2️⃣.1️⃣понять, подчинить, видоизменить и online-контролировать dtls-ключи/серты/хеши 3️⃣ -//- 4️⃣поддерживать всю эту конструкцию в боевой готовности 24/7, при том что "где-то-посередине" все время плавает и легко может быть/стать недоступным, непригодным по тех.условиям, а то и вовсе - неизвестным 5️⃣всем этим должен управлять большой международный штат высококвалифицированных специалистов, выполняя большую часть работы вручную, причем в спешке, т.к. звонок происходит здесь и сейчас 6️⃣и все это, весьма вероятно, лишь ради: "Привет, как ты? - Занят, перезвоню" Как видно, нормально реализованные звонки (srtp+dtls) разломать не так уж и просто, если вообще возможно. Конечно, в реальности никто подобной хуйней заниматься не станет. Имея такие ресурсы, гораздо проще обратиться в гугл/эпл и вежливо попросить удаленный доступ прямо к телефонам a/b, откуда удобненько подснять не какой-то там рандомный звонок, а СРАЗУ ВСЕ, по всем мессенджерам, в расшифрованном виде и с удобным интерфейсом. От подобного развития событий ни один мессенджер защитить, естественно, не в состоянии, но сейчас это выходит за рамки обсуждения. Завершая тему звонков, стоит также упомянуть webrtc, который порой заявлен как протокол шифрования звонков. Но в действительности, шифрование звонков внутри webrtc всегда реализовано..? правильно - srtp+dtls. Справедливости ради, надо сказать, что webrtc - это далеко не только звонки, и далеко не только шифрование. Это довольно обширная веб-технология, обсуждать которую мы опять же сейчас не будем. Итого по звонкам: srtp+dtls - хоть и 2 раза server-based, хоть и теоретически уязвим, но в реальной жизни он будет надежен в 99.9% случаев А если с обеих сторон - a и b - еще и по даблвпну натянуть (bespale, например😁) При реализации звонков, протокол dtls используется исключительно для обеспечения целостности и защиты от mitm, сами же данные (разговор) шифруются по протоколу srtp Также, вы можете встретить громкое заявление о том, что звонки у нас, мол, шифруются по новой webrtc-технологии Но ковырнув пальцем буквально на пару ссылок дальше википедии, мы легко можем обнаружить, что шифрование в этой новой технологии реализовано (ну надо же) по протоколу srtp+dtls (бывает же) Но, надо признать, что webrtc - это не только звонки, технология довольно обширная, в частности позволяет обмениваться файлами, правда какие протоколы применяется в этом случае - редакция сказать затрудняется, может кто подскажет, предположительно все те же srtp+dtls.. _ Итого по е2е для звонков: это всегда srtp+dtls И это значит - 2 раза server-based Звонки - единственный тип соединения, где основные пакеты с данными (разговорами) летят строго p2p, минуя сервер мессенджера Но при этом тухлый золотой и единственный стандарт е2е-шифрования звонков - делает доверие к серверу (привет владельцу/разработчику) - КЛЮЧЕВЫМ параметром безопасности при совершении звонка Какая ирония, вы не находите?😁 2.2.10. промежуточный итог 2

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

Итак.

#1️⃣ Надежно зашифровать sодержание можно с помощью следующих симметричных алгоритмов: 📍aes (128/256) и/или 📍Salsa/ChaCha #2️⃣ Надежно распределить ключи можно с помощью: 📍(ec)dh #3️⃣ Надежно защититься от человека-посередине можно с помощью: 📍sha и/или polly #4️⃣ Правдоподобно отрицать поможет: 📍протокол 1 ключ - 1 пакет #5️⃣ Ну и все коммуникации делятся на 3 типа данных: 📍текст 📍файлы 📍звонки Ну воооот Если по всем пунктам - все хорошо, то только тогда это будет надежное е2е-шифрование (т.е. всего лишь 1 параметр оценки). А еще ведь был владелец/разработчик😁


Источник телеграмм канал - https://t.me/bespaleph0ne

12 просмотров0 комментариев

Недавние посты

Смотреть все