Что же касается ssl/tls, то это по факту - https, т.е. - шифрование между посетителем и сайтом.. ну не знаю стоит ли тут вообще распинаться..
ну ладно😁
❗️помимо того, что это бессмысленно изначально: за каждым сайтом все равно стоит своя сорм-коробка, а то и несколько, да и владельцы в 99,99% - стукачи
❗️помимо того, что сам протокол насквозь дырявый и критические уязвимости находят по сей день, собственно поэтому он и обновляется постоянно: ssl1->ssl2->ssl3->tls1->tls1.1/1.2/1.3
❗️помимо того, что человеку-посередине нужен лишь БЕСПЛАТНЫЙ ssl-strip (kali linux) для полной дешифровки пакетов

помимо всего этого, есть у ssl/tls одна фатальная, корневая, нерешаемая проблема - сертификаты и сертифицирующие центры
смысл вот в чем:
ssl/tls должен не только зашифровать пакеты, но и удостоверить нас в том, что пакет летят между нами и конкретным сайтом, оригинальным сайтом
Мы должны как-то точно узнать, что вводим свои логин/пароль именно на сайте своего банка, а не на фишинговом сайте с похожим доменом, например
Обеспечить это знание нам и должен некий сертифицирующий центр, путем выпуска сертификата для открытого ключа нашего банка
Т.е. некий центр проверяет и удостоверяет, что банк - это банк, домен принадлежит банку, открытый ключ принадлежит банку и все тут четко и законно, это типа решает проблему распределения открытых ключей
Такой нотариус в интернете, авторитетная персона, которой мы должны поверить
Ну уже сами чуете куда идет, да?😁

Проблема с сертификатами и их центрами (а следовательно и с ssl/tls) в том, что они не могут выполнить ни одной поставленной задачи, они не работают ни в одном направлении:
➡️это не может защитить нас от фишинга: вспоминаем клаудфлер (мир его дому) и то, как легко он раздает свои серты (абсолютно такие же, законные, ничем не хуже других, в адресной строке все зелененькое и подтвержденное, как у настоящего банка) ботоводам, кардерам и фишерам
⬅️это не может обеспечить нам хоть мало-мальской сохранности данных: мусора приходят в сертифицирующий центр, выпускает себе дубль ключа/свой ключ, и дальше разгоняются как хотят - возможностей перехвата/дешифровки/разъеба просто не счесть

Резюмируя по ssl/tls:
❗️несмотря на https в адресной строке, все что мы оставили в открытом белом интернете (и не только) - мы оставили В ОТКРЫТОМ ВИДЕ НА СТОЛЕ У МУСОРА, оставили НЕСКОЛЬКО РАЗ НАВСЕГДА, а может еще и кибер-бродягам подарили по дороге
✔️это применимо только когда мы - владелец сервера, и хорошо при этом понимаем что, как и зачем делаем, исключительно в личных целях; с точки зрения обычного юзера этот протокол не дает почти никакой безопасности - фиговый листок

_

Резюмируя в общем, по асимметрии↪️↩️:
❗️заявленная задача (распределение ключей) - не решена, т.к. открытый ключ - палит всю хату, лишая нас возможности правдоподобно отрицать
Следовательно неважно симметрично🔄 мы будем шифроваться или асимметрично↪️↩️, проблема все равно остается, нам все равно придется как-то беспалевно распределять ключи между aa и bb
❗️любое клиент-сервер шифрование (tls) предполагает расшифровку пакетов на сервере и не является для нас сколько-нибудь надежным, за исключением случаев, когда мы сами владеем/управляем тем сервером, или доверяем его владельцу/админу
❗️сертифицирующие центры - галимые нотариусы, а их сертификаты - галимые доверенности, и уж точно эта концепция никак не помогает решить проблему распределения ключей (в данном случае открытых)
❗️не имеет технических преимуществ перед симметрией🔄, т.к. все те же угрозы - (1)ключи, (2)mitm, (3)отрицание - остаются актуальными
❗️в голом виде (rsa) - это медленно

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

Что касается полноценных, но при этом сугубо 🔄симметричных протоколов (по аналогии с pgp и ↪️↩️асимметрией), то их просто не существует в природе, т.к. распределение общего секретного🔑 ключа невозможно организовать симметрично, придется изъебываться, будет уже не голая симметрия

Но зато, существует прекрасный симметричный алгоритм, который делает читаемое - 100%-но нечитаемым, быстро, с гарантией и одним 🔑 на выходе, и ебитесь с ним дальше как хотите
Называется этот алгоритм - aes(1998)
можно сказать что он пришел на смену алгоритму des(1997), хотя напрямую ему и не наследует

✅✅✅aes, если это 256 бит - это максимально надежно, это не ломается, это широко применяется не только в рамках е2е, но и для локального (офлайн) шифрования, например диска или флешки

в забеге симметричных алгоритмов у aes, конечно, есть конкуренты: всякие рыбки и кузнечики
одни из них вроде бы не так плохи, но уступают в скорости
другие - имеют сертификацию фсб (как вам такой серт-центр?😂)

В целом, нет ни одной логичной причины использовать другой алгоритм вместо aes, по крайней мере в части локального шифрования уж точно.

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

Хорошо это или плохо, и что это вообще значит - редакция судить не берется😁
✅Отметим лишь, что топовый на сегодня представитель этого потокового семейства - chacha20 (2015) - завоевывает все большую популярность, в частности все тот же cloudflare использует chacha20 для допиливания tls-протокола
✅На эту чачу пока не нашли никаких дырок, клаудфлер применил этот алгоритм почти сразу (15-16 год) и не отказался до сих пор, впрочем и от aes он тоже не отказывался и вряд ли собирается
✅Ну и кроме того, потоковое типа быстрее блочного, хотя на скорость aes, опять же, массовых жалоб не поступало

Итого по 🔄симметричным алгоритмамалгоритмам:
Есть два достойных представителя - aes и chacha20
Один - опытный и проверенный годами профи, доказал свое право на трон в несметном количестве онлайн и офлайн сражений
Другой - молодой и дерзкий боец, с необычной техникой молниеносных ударов и пока что идеальным ре́кордом, но без адекватной локальной (офлайн) реализации, ждем его в veracrypt

Редкий раз, когда можно сказать - оба лучше👍

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

Теперь
Чтобы из надежного алгоритма сделать надежный протокол нам необходимо решить все те же 3 насущных проблемы шифрования:

1. распределить ключи: будь они открытые или закрытые, постоянные или временные - их надо распределить между aa и bb таким образом, чтоб ни одна

2. блядь-посередине не смогла получить доступ ни к ОТКРЫТЫМ ключам, ни к ОТКРЫТЫМ пакетам тем более, а также желательно не дать ей доступа к ОТКРЫТОЙ метадате/чексуммам/сертам и прочей мелочи, которая сопровождает наши пакеты-с-содержанием.. и все это для того, чтобы оставить нам возможность

3. правдоподобно отрицать свою причастность ко всем этим пакетам/ключам/метадате/тяжкимпреступлениям


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

В частности некто Диффи и его кентаврик Хеллман задумались о (1) распределении ключей довольно давно, и уже в 1976 представили миру свой протокол Дифи-Хеллмана (dh) - протокол обмена секретным 🔑ключом между aa и bb, которому не страшен никто посередине, а ключ гарантировано достается только aa и bb
Технически это выглядит примерно так:
1. от каждого собеседника берем по 2 открытых параметра и по одному закрытому - всего 3 на каждого
2. складываем-умножаем-делим-курим-🧙‍♂️-симсалабим: получаем уникальный dh-параметр (ключ/серт/подпись/хз😁) для каждого из собеседников
3. берем по такому dh-параметру от обоих , ✖️➗➕➖💱🧙‍♂️ - получаем общий 🔑 секретный ключ, причем получаем его локально, не передавая и не принимая его по сети

Можно еще так сказать:
dh берет, условно, (1) наш @id, (2) время последнего онлайн, (3) свой алгоритм, (4) коррелирует это с нашим собеседником (посредством открытых id и времени)
(5) И прямо в телефонах (нашем и собеседника), локально, вычисляет секретный ключ, который одинаков для нас обоих и его не надо никуда передавать

Классная схема, памятник им надо поставить

Но с '76 года прошло немало времени, вычислительные мощности подросли, и диффи-хеллмана пришлось немного доработать, добавив к нему каких-то эллиптических кривых (🤷‍♂️🙈даже не спрашивайте), назвав это все вместе - Elliptic curve Diffie–Hellman, или ecdh (2005)

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

И тут мы опять упираемся в этого уебского
(2) человека-посередине
да, от него надо защищать не только основные пакеты, но и процесс распределения ключей, даже если он проходит с помощью ecdh
От него надо вообще защищать все, причем в данном случае речь не столько о прослушке (от этого должно защитить шифрование), сколько о подмене
Подмене dh-параметров/ключей и уже в конечном итоге - самих пакетов с содержанием, что грозит нам уже не просто прослушкой, а самой что ни на есть "мам, скинь 100 рублей на телефон, я человека убил"

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

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

Еще можно сказать что хеш - это шифрование, но только в одну сторону, без возможности получить из хеша исходный пакет в принципе

Соединяя хеш-функции с асимметричным шифрованием мы можем обеспечить
✔️во1 аутентичность - открытый ключ подтверждает личность
✔️во2 целостность - шифруя хеш закрытым ключом мы исключаем возможность его подделать человеком-посередине

На сегодня оптимальным алгоритмом проверки целостности и аутентификации можно назвать sha (1995), а точнее его самого молодого правнука - sha3 (2012)
Такая конструкция надежно защитит нас от этого уебка-посередине: если он попытается что-то перехватить и подделать - у нас сразу перестанет биться пакет/хеш/расшифровка хеша

Также, для проверки целостности и аутентификации существует еще в природе, и кстати довольно широко используется протокол - dtls (2012)
Но вы уже умненькие, и видите там недвусмысленное - tls, а это значит server-based-протокол, со всеми вытекающими
И тем не менее, dtls - формально весьма безопасно, имеет право на жизнь
Но sha получше будет все-таки: математика против человека, выбор очевиден

Будем считать, что проблему-посередине мы решили
Но.. опять же😁 нюансы-нюансы:
Вот они ворвались-посередине, и пусть мы об этом узнаем и беседу прервем, но ключи-то они уже получили, получается
Представим себе эту неприятную ситуацию
Представим и наконец подойдем к 3ей насущной проблеме шифрования:

(3) правдоподобное отрицание
причем в данном случае мы имеем ввиду сугубо техническую сторону вопроса:
вот он-посередине ворвался и получил ключи - все, на этом будем считать вопрос правдоподобного отрицания закрыт, и далеко не в нашу пользу

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

ids и симкарты ключи шифрования надо менять чем чаще, тем лучше, в идеале - каждое новое сообщение шифруется новым ключом, ну или хотя бы каждая 5-10 минутная сессия
Обновляем ключи (все: и 🗝, и🔑, и для dh и для sha, и для сессий, и для файлов, итд), старые удаляем - профит
Все, что было зашифровано старым ключом - потеряно навсегда, а значит там и отрицать нечего
Меняем ключи - рвем связь, все очень просто и логично, примерно как с ids😉

Подведем небольшой итог:

✅надежно зашифровать пакет на своей стороне перед отправкой - можно, алгоритмы имеются - aes, chacha20, rsa

✅надежно распределить ключи между aa и bb - можно, протоколы имеются - ecdh (+sha, например)

✅надежно защититься от человека-посередине, включая и сервер самого мессенджера - можно, протоколы имеются - sha, например

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

_

Если собрать все эти 4 "можно" в одном протоколе - такой протокол можно будет назвать сквозным/оконченным/е2е: распределили ключи, подтвердили целостность/личность, зашифровали, подтвердили целостность, поменяли ключи, распределили ключи.. - так это должно выглядеть
_
tbc

Итак, мы рассмотрели наиболее базовые вещи (протоколы/алгоритмы)
Я не зря так подробно останавливался на aes, chacha20, rsa, dh и его ec, sha, потому что все это - базовые вещи, базовые алгоритмы/протоколы
Именно они (или их менее именитые аналоги) и лежат в основе любого современного е2е, что мы сейчас наглядно и увидим, и для чего мы так дотошно это все и разобрали

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

Но перед тем как уже перейти к столь разным и столь одинаковым современным протоколам е2е, надо еще упомянуть пару вводных моментов

Момент первый (совсем простой):
🔢цифры
ко всем указанным ранее протоколам/алгоритмам, как правило прилепляют в конце какую-то цифру, например: aes128/rsa4096/dh2048/sha256 и так далее
Буквы мы теперь хорошо понимаем что означают (ну +-😁), а вот что значат эти цифры.. о чем они нам говорят?
Все, как и всегда, довольно просто:
цифры эти указывают всего-навсего на физический размер ключа/серта/хеша

Этот размер исчисляется в битах (единица создания информации)
Именно поэтому эти странные цифры всегда делятся на 8 - чтобы из битов получить байты (единица хранения/пересылки информации)

Т.е. aes256 - означает, что для шифрования создан и применен 256-битный ключ
rsa2048 - 2048-битные ключи (🗝🔑)
и так далее по аналогии

Как это трактовать применительно к обеспечению безопасности?
Можно сказать так:
чем больше цифра, тем физически больше ключ/хеш (т.е. ключ rsa4096 прям ровно в 2 раза больше ключа rsa2048), тем лучше

Но
Так это работает строго в рамках одного протокола/алгоритма, т.е.:
rsa4096 лучше чем rsa2048,
а
aes256 лучше чем aes128 (хотя идут споры)
а
sha512 лучше чем sha256

но
sha512 НЕ лучше чем aes256, а rsa4096 - НЕ лучше их обоих, только лишь потому что там циферки больше

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

Думаю по 🔢цифрам разобрались

Теперь момент второй:
💱типы данных (типы пакетов)

Условно говоря всю нашу интернет коммуникацию можно разделить на три типа:
1. текст
2. файлы
3. звонки

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

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

Чего не скажешь о хотя бы даже картинке, которая весит как несколько десятков, а то и сотен текстов, соответственно делим скорость на 10-100
Не говоря уже о видео

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

Зачастую файлы если и шифруются, то сервер-бейсд (tls), что, как мы хорошо понимаем, никакого е2е между aa и bb не обеспечивает - сервер-то увидит наши пип-фоточки, какое ж это е2е

Поэтому, мухи отдельно, котлеты отдельно
Смотрим отдельно что там с е2е по тексту
и
Смотрим отдельно что там с е2е по файлам

К тому же, это и реализовано как правило по-разному, хотя все еще с применением тех же, одинаковых, базовых протоколов/алгоритмов - aes/rsa/dh/sha/аналоги

Ну и совсем отдельно стоят звонки
И в данном случае выделяются они не размером пакетов, а типом соединения
Дело в том что звонок может быть реализован, только не смейтесь, сугубо и исключительно p2p
Да-да, всегда когда мы звони́м - мы общаемся p2p, напрямую, пакеты с данными (голосом) - летят сугубо между aa и bb, не заходя на центральный сервер вообще
И хотя мы уже взрослые и прекрасно понимаем, что сервер все равно должен быть, чтобы вывести нас обоих онлайн, сконнектить, создать эту p2p-сессию, итд, все равно, это p2p-по-данным дает нам некие бонусы
Итого, идет звонок:
пакеты с данными - не летят на сервер вообще
а вот пакеты с метой (в том числе ключи) - вполне себе идут через, а порой и вообще - создаются/генерируются на промежуточном сервере
Зафиксируем этот технический момент для понимания


И если по тексту/файлам мы имеем хоть какие-то базовые вариации (хотя тоже довольно иллюзорные), какие-то различные адаптации/варианты применения, какие-то аналоги, какое-то развитие..
То когда мы взглянем на звонки, то здесь в 99% все упрется в комбинацию srtp(2004)+dtls(2012) - это золотой стандарт отрасли
А по мнению редакции - так себе стандартик

Что такое srtp?😁
Внимательно следите за руками:
📍aes128 (*модернизированный из блочного в поточный) - само шифрование
📍диффи-хеллман в паре с серверной асимметрией - распределение ключей
📍sha (первой версии, старой и херовой) - целостность, защита от mitm
📍один звонок - один ключ - отрицание

Как видите, все - знакомые лица
Все знакомые, но не все - приятные, в частности sha первой версии явно хромает
Но главное что смущает - сервер-based распределение ключей, пусть и через диффи
Надежность сертов и центров, их выдающих, мы уже обсудили выше, не будем сейчас заострять на этом

Для дополнительной защиты от человека-посередине к srtp чаще всего добавляется dtls (тоже серверный протокол, не странные люди?)

Что такое dtls?😁
aes128+ecdh+sha256+tls - ого, свежие лица подтянулись

При реализации звонков, протокол dtls используется исключительно для обеспечения целостности и защиты от mitm, сами же данные (разговор) шифруются по протоколу srtp

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

_

Итого по е2е для звонков: это всегда srtp+dtls

И это значит - 2 раза server-based

Звонки - единственный тип соединения, где основные пакеты с данными (разговорами) летят строго p2p, минуя сервер мессенджера
Но при этом тухлый золотой и единственный стандарт е2е-шифрования звонков - делает доверие к серверу (привет владельцу/разработчику) - КЛЮЧЕВЫМ параметром безопасности при совершении звонка

Какая ирония, вы не находите?😁

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

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

📌базовые алгоритмы шифрования:
🔄🔑: aes, chacha20
↪️↩️🗝🔑: rsa, ssl/tls/*

📌протоколы распределения ключей:
базовый - ecdh (диффи на стимуляторах)
дополнительно - ↪️↩️ серверные варианты (асимметрично через сервер распределяем общий симметричный ключ на сессию)
дополнительно - целостность и аутентификация ключей (хеши, sha и прочее)
также - эллиптические кривые вроде бы используются как-то самостоятельно, без диффи и без хеллмана даже, но точнее сказать затрудняюсь
также - существует концепция пре-ключей, типа ключей для ключей для ключей (чтобы ты мог выпускать ключи, пока выпускаешь ключи), опять же без технических подробностей, но полагаю, что внутри этой концепции, как всегда - свежие и неожиданные лица

📌протоколы целостности, верификации, аутентификации
чемпион - sha, желательно бы 512 бит и 3 версию, есть родственники/предшественники и прочие аналоги, сейчас не принципиально
также - некий протокол аутентификации/подтверждения пакетов polly с какими-то цифрами сбоку, но их уже и я не очень понимаю.. стоит отметить, что polly всегда (или часто) находится рядом с поточными аналогами aes'a - chacha/salsa
Совпадение? Не думаю знаю.. но как бы там ни было😁
также - ↪️↩️ серверные варианты (через публичный ключ сервера верифицируем там какие-то свои/чужие ключи, что-то в этом роде)

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

📌е2е - это три направления: текст/файлы/звонки
каждое из направлений рассматриваем отдельно, т.к. и реализовано оно по-разному

📌базовый и единственный существующий протокол е2е для звонков - srtp+dtls, он же - webrtc, внутри которого лежат банальные aes/dh/sha/ssl

📝Вот примерно с такой е2е-базой в голове стоит подходить к дальнейшей оценке потенциальных претендентов по критерию "е2е-шифрование"

-
tbc

ой, опечаточка вышла
алгоритм des (предшественник aes), конечно не 1997 года рождения, а старше ровно на 20 лет, т.е. 1977 года
des - ровесник rsa, 77 год, не 97, прошу прощения, промахнулся чутарик😅

Ну шо, малята😏
Продолжим

В предыдущих сериях мы настойчиво пытались ответить самим себе пока что на самый простой вопрос:
1️⃣❓возможен ли безопасный канал удаленной связи в принципе, хотя бы теоретически?

Рассуждая, мы ввели (пока что) два критерия оценки:
1.Владелец/разработчикВладелец/разработчик
2. e2e шифрованиеe2e шифрование

Мы наглядно рассмотрели:

✅технические принципы (🔄/↪️↩️) и 3 основных проблемы (ключи/mitm/отрицание) шифрования

✅историю возникновения и развития, алгоритмы/протоколы/терминологию (rsa/aes/dh/sha/tls/pgp)

✅зачем к буковкам добавляют 🔢циферки

✅типа данных (текст/файлы/звонки), и почему звонки - это не очень безопасно априори (srtp+dtls)

__

Мы неплохо так поднаблатыкались, скажу я вам, мои золотые

В этой серии мы рассмотрим наконец актуальные и рабочие е2е-решения, таким образом слегка затронув уже более интересный и насущный вопрос:
2️⃣❓существует ли сегодня в природе практическая реализация такого [безопасного] канала?

Но😁

Вы будете плакать смеяться, но к 1️⃣❓ нам еще ой как предстоит вернуться, рассмотрев еще один ооооочень важный (основополагающий) критерий, а также горстку менее важных и основополагающих параметров
Но не пугайтесь
Там уже не будет особых сложностей, шифрование - самый большой, сложный и заебистый заеб, в который труднее всего врубиться
Но если мы хотим ОТВЕТСТВЕННО И ЧЕСТНО ответить себе на 1️⃣❓ - врубиться придется

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

__

Итак
❓Рассматриваем актуальные и полноценные е2е-протоколы (в привязке к конкретным мессенджерам - участникам рейтинга)
❓Добиваем оставшиеся критерии/параметры безопасности канала, добив таким образом 1️⃣❓
2️⃣❓Рассматриваем актуальные и полноценные (ох.. далеко не все😂) мессенджеры
❔ну и там дальше больше😁

Погнали

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

Вы уже догадались, да?😁
Прошу любить, уважать, жаловать и использовать:

Off-The-Record Messaging, больше известный как OTR (2004)
Основа основ е2е, протокол будет внесен в учебники истории, без сомнения

Чем же он так хорош этот otr, спросите вы?
Разберем техническую сторону:
✔️aes128 - шифрование
✔️анонимный (доработанный) dh - ключи
✔️sha256 + общий секрет (опционально) - mitm
✔️[ну и главное] полный рандом и вакханалия по ключам: одно сообщение - один ключ - отрицание

Собственно, что это вообще такое - otr?
Это - е2е-протокол + практическая реализация (плагин)
Это - не мессенджер, через otr нельзя послать сообщение, только зашифровать

otr - это шифрование для жабы (jabber/xmpp), плагин который ставится/предустанавливается в жаббер-клиент
Строго говоря, вся безопасность жабы - это и есть отр, без него жаба не безопасней имейла/смс/разговора в кабинете прокурора

Да, у отр существует более старая (и как мы поняли херовая) альтернатива - pgp, а есть более новая (и по внешним техническим признакам - вполне себе лучше отр) - omemo (2015)

омемо мы обсудим совсем скоро, он и вправду весьма неплох

Но жаба+отр - это эталон, это классика жанра, этим пользуются все обитатели серо-черной сети (от каржа до кайфа), это проверено, это мега-надежно, это абсолютно точно позволяет пренебречь сервером по части пакетов (но не по части паролей, например, сервер все-таки😁)

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

Разберемся
И начнем с начинания😁:
✔️анонимный (доработанный) диффи-хеллман
доработали они старину диффи довольно простыми и уже понятными нам методами - (1) добавили асимметрии↪️↩️, (2) добавили хеш (sha)
Сегодня последователи otr затюнинговали этого dh-франкенштейна еще сильнее, но дойдем до этого позже

А продолжим золотым стандартом отрасли (и в данном случае вообще без иронии, он внатуре золотой):
✔️ одно сообщение - один ключ
как мы помним, dh вообще в целом нужен для того, чтобы сгенерировать общий одинаковый🔑 ключ для aa и bb, чтобы шифровать дальнейшие сообщения (пакеты) 🔄симметрично
Так вот, в отр этот dh-франкенштейн каждый раз создает новый 🔑 для каждого нового сообщения, и от aa и от bb
Т.е. в данном случае 🔑 у них хоть и общий, хоть он и одинаковый, но он КАЖДЫЙ РАЗ РАЗНЫЙ
Каждый пакет (сообщение) сопровождается новым dh-набором для генерации нового ключа, и при этом от каждого собеседника исходят разные dh-наборы, никак не связанные с предыдущими пакетами и никак не связывающие собеседников друг с другом, что обеспечивает нам отрицание не только пакетов, но и собеседника!!!
Кроме того, если паяльник все же сделает свое дело и мусора получат доступ к компу с нашими отр-ключами - это им никак не поможет расшифровать накопленные ранее пакеты, т.к. с помощью этих ключей, хранящихся на нашем компе, невозможно расшифровать/сгенерировать те одноразовые ключи для сообщений, а следовательно - пакеты, а следовательно - сосать они хотели
Отправлено, прочитано, похоронено - счастье
otr доказал и наглядно показал, что правдоподобное отрицание - это не вопрос паяльника в жопе, это вопрос алгоритмов и протоколов, технический вопрос

✔️также, отр внедрил интересную и необычную защиту от mitm - общий секрет
Это прям буквально перед установлением отр-сессии один собеседник должен правильно ответить на вопрос другого
Правильно - т.е. буква в букву
Оригинальное решение, имеет право на жизнь, сам пару раз пользовался, но больше ради приколюхи
В народ не пошло скажем так..
Да и какие у тебя могут общие секреты с барыгой/кардером/продавцом акков/логов/людей?😁 А ведь именно эти и близкие им по духу/профессии люди - и есть основные пользователи жабы+отр

Короче
В общем и целом, отр - е2е папа, тут даже обсуждать нечего
Да он немного постарел, да молодые дети-собратья-конкуренты в чем-то лучше, быстрее, сильнее, приветливее, удобнее
Но отр прошел не один миллиард битв с идеальным рекордом, он все еще непобедим для врагов, а большего от него и не требуется

Сомневаешься? Никому не веришь? В розыске? В приступе?
Твой выбор - жаба+отр, не прогадаешь


Теперь что касается самоопровержения
Ну тут все просто: среди разработчиков отр-протокола значится такой человек как Никита Борисов, вполне себе тянет на ру-снг, правда?😁
Также там есть некий Крис Александр, полагаю тоже где-то рядом, или корни, хотя не факт конечно, но не суть, одного россиянина вполне достаточно😂
Борисов на википедии, так вообще, чуть ли не главным разработчиком назван
Не возьмусь судить главный-неглавный, вроде бы главный - Ян Голдберг (канадский профессор, киберпанк, имеет отношение к тор-движению и все вот это), по крайнем мере он - лидер проекта по сей день.. хз в общем..

Вот такое ру-снг вам, пожалуйста
Самое надежное на всем белом свете, не хотели?😁
OTR - это то самое исключение, которое лишь подтверждает правило
Cкоро и сами увидите какое там остальное ру-снг😣

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

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

Но и с текстом не все так гладко
отр - протокол, предполагающий одновременный онлайн для aa и bb, иначе не получится установить сессию
Если жаббер-клиент стоит на телефоне, это не представляет особой проблемы, т.к. такой клиент будет 99% онлайн
Но если это комп - очевидно онлайн упадет как минимум вполовину
Но даже 1%, даже секунда офлайна любого из собеседников - это разрыв сессии
Разрыв сессии - это ее ручной перезапуск, иначе одному летит шифрованное старой сессией, а другому - новой, что представляет из себя некую проблему по безопасности, строго говоря.. Но на практике таких нечитаемых сообщений будет послано не больше 2-3 в каждую сторону, что сводит риски в общем-то в 0

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

И тем не менее, это - проблема, можем условно назвать ее "доставка пакетов в офлайн"
А суть вкратце выразить так: если aa офлайн, а bb в этот момент послал ему пакет, то такой пакет должен остаться читаемым для aa, когда он таки выйдет в онлайн
Не в пример отр, где aa в этом случае придет нечитаемая хуйня. Кстати, эта хуйня - ровно то, что обычно видят все остальные по дороге, включая жаббер-сервер(-ы)

Итого по жабе+отр
1. текст - да (максимально надежно, но есть неудобства)
2. файлы - нет, дырка
3. звонки - нет в принципе

И если продолжать метафору отр-куста, то сам отр в этом раскладе - папа, ну или мама, родитель одним словом.. или корень куста😁
И у этого родителя есть один единственный сын (ну или дочь.. ну или ствол куста):

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

Протокол Сигнал - идейный последователь отр, о чем не стесняясь заявляют сами разработчики
Они взяли лучшее от отр, подкрутили основу, добавили битности, сильно усложнили и доработали ключи, доработали основной е2е-протокол, добавили файлы, добавили звонки

По факту, среди индустрии и ее капитанов именно сигнал сегодня олицетворяет собой золотой стандарт:
Если отр - профи, трудяга, отец, заложил основу, установил стандарты качества, но уже потихоньку готовится к пенсии
То сигнал - супер-профи, сын, которым можно гордиться, максимально развил наследство, добился поистине мирового признания, после чего наплодил уже огромное количество своих детей.. или братьев.. или клонов.. или последователей.. или веток куста😁

Впрочем судите сами:
📌протокол сигнал (так или иначе, полностью или частично, с доработками и без) сегодня используют говорят, что используют:
whatsapp
viber
facebook messenger
skype (microsoft)
google alo (проект закрыт в '19)

📌протокол сигнал и/или его отдельные куски сегодня реально используют в своих е2е-протоколах:
omemo (жаба)
matrix (riot)
proteus (wire)
а также, как я только что с удивлением для себя обнаружил, некий:

session (бывший Loki Messenger)

- кстати интересный персонаж.. совсем новенький, февраль '20, блокчейн там какой-то.. лан, посмотрим че за фрукт потом как-нибудь😁

Вот вам и отр-куст🎋
Возможно туда следовало бы определить кого-то еще, но точно никого больше из нашего рейтинга

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

Сейчас разберем сигнал до косточек
Начнем с текста

Внутри большого общего протокола сигнал (т+ф+з) конкретно за текст отвечает еще один, внутренний, отдельный протокол - Алгоритм двойного храповика, также в прошлом Аксолотль
[здесь как раз тот случай с путаницей протокола/алгоритма, в рамках нашей терминологии он должен был бы называться Протокол двойного храповика]

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

Но прежде чем перейти к сухим буковкам и циферкам, сначала мы немного разжуем особенности и отличия от базового отр

Итак, для обмена ключами сигнал
1. взял отрвского dh-франкенштейна
2. вычленил оттуда самого dh
2.1. накачал его стимуляторами эллиптическими кривыми
2.2. размножил на три круга
2.3. усадил на свой сервер
2.4. теперь это стал 3-dh на э.к. и при этом server-based (но это безопасный server-based, не то что tls, тем более это только ключи)
3. вычленил кусок с асимметрией↪️↩️, основательно его переработал и назвал это - преключипреключи (ключи для ключей для ключей для.. чтобы ты мог.. пока.. ну вы помните😁)
4. хеш оставил в покое, подкрутив сугубо технико-числовые показатели (не качественные)

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

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

📍если в офлайн, то преключи + диффи
насколько понял эту концепцию: телефон тупо генерирует 100 открытых преключей, впрок, на случай офлайна, скидывает их на сервер, после чего эти преключи в сочетании с диффи используются собеседниками для генерации сессионных aes-ключей для входящих в офлайн пакетов, а когда тот телефон опять выйдет в онлайн, то согласовав с сервером какой ключ куда пошел, опять же через диффи, сгенерирует локально aes-ключи для расшифровки скопившихся пакетов
При этом перехват этих новых ключей посередине ничего не дает, потому что обратно без главного ключа, хранящегося локально в телефоне, они не работают, асимметрия же😁
Поэтому в данном случае server-based безопасен.. хотя легкая паранойка все же остается, да?😅

📍если в онлайн, то диффи (генерация) + хеш (подтверждение), в стандартном отр-режиме

С ключами вроде разобрались, теперь можно доставлять в офлайн, ништяк

Давайте уже наконец рассмотрим этого двойного храповика/аксолотля в разрезе букв/цифр:
✔️aes256 - шифрование
✔️3-dh(ec)+prekeys+hmac(хеш) - ключи
✔️hmac+sha256 - mitm
✔️один пакет - один ключ + рандомные, новые, необратимые в старые ключи (серверный dh) - отрицание

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

Но общий большой протокол сигнал - это не только текст, он еще и умеет в е2е по файлам и звонкам, разберемся:

✔️Файлы
Честно говоря, информацию о том шифруются ли файлы в сигнале, и если да, то как именно (протоколы/алгоритмы) найти было не так уж и просто, что несколько смущает
Ни в каких faq/whitepapper/исследованиях/аудитах оно так на поверхности вообще не лежит.. А хоть бы даже в пресс-релизе или рейтинге каком - ни слова, как будто нет этой проблемы
Но покопавшись в репозитории сигнала на гитхабе удалось обнаружить что attachments (полагаю это оно, файлы) шифруются по алгоритму ✔️aes256, а целостность подтверждается ✔️hmac-sha256
После чего, все это загружается на сервер и ждет скачивания реципиентом

Логично предположив, что ✔️обмен ключами пойдет по аналогичному сценарию (3-dh(ec)+prekeys+hmac), а ✔️на каждый файл будет отдельный ключ, то мы можем допустить абсолютно такого же самого двойного храповика и для файлов

Но
Это предположив и допустив
Почему этой информации нет в очевидном и легкодоступном месте - решительно непонятно
Но допустим

✔️Звонки
Ну здесь все максимально прозаично
Сначала это было просто zrtp (т.е. пресловутое srtp + dh для ключей), без доп защиты от mitm, т.е. без хеш/dtls/или чего-то подобного
Позже (2017) сигнал перешел на webrtc (=srtp+dtls, как мы помним)
Короче тут без сюрпризов😁

__

Резюмируя по сигналу:
✅текст - двойной храповик (т.е. отр+)
✅файлы - он же (с вероятностью в 99%)
✅звонки - webrtc, т.е. srtp+dtls

И это можно назвать первым комплексным е2е одновременно по всем 3 типам данных
И это круто
[Но сам мессенджер - говно, напоминаю😁]

Разберем оставшийся отр-куст
А точнее только его достойную часть - тех, кто реально делает, а не просто ляля разводит
Пойдем в историческом порядке

Итак, сигнал, включая двойного храповика был опубликован в 2013
И первая ветка куста отросла уже через год - matrix (2014)

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

✅текст
они взяли сигналовского двойного храповика, пересобрали на свой лад, назвали это olm (2014-2015-2016🤷‍♂️) получилось примерно то же самое:
✔️aes256 - шифрование
✔️3-dh(ec)+prekeys+hmac-sha256sha256(хеш) - ключи
✔️hmac+sha256 - mitm
✔️1 пакет - 1 ключ, все по классике сигнала/отра - отрицание

На мой дилетантский взгляд, отличие лишь в усиленном (+sha256sha256) хеше для ключей, но возможно у сигнала это тоже есть, просто я не понял
В любом случае, изменения если и есть, то весьма косметические, возможно что-то реализовано/адаптировано несколько иначе
По сути, olm - близнец двойного храповика

Но текст у матрикса - это не только olm, это еще и megolm, который был создан для групповых чатов (т.к. отр-дв.храп-олм - это все про общение сугубо промеж двух людей, только aa и bb)

Первое отличие megolm от olm - распределение/согласование ключей, что и обеспечивает собой возможность групповой сессии
Схема по ключам у меголма такая:
✔️Ed25519 (2011) - это ↩️↪️обратная асимметрия, основанная на rsa+sha512, она же цифровая подпись, при этом тоже на каких-то там эллиптических кривых и сервер-бейсд
+
✔️некий 1024-битный хеш для подтверждения целостности.. что за хеш, точнее не скажу, похоже на собственное, кустарное производство, хз в общем

Эта меголм-ключ-конструкция призвана, все так же, распределить симметричный aes-ключ, но не только между aa и bb, а еще и между cc, dd, etcetc

Шифрование и целостность аналогично олм - aes256+hmac-sha256

А вот с отрицанием тоже имеются проблемки у меголма
Почему тоже?
Потому что здесь и ключи распределяются херово, в частности закрытые aes-ключи пересылаются по сети (!!!), пусть и в хешированном виде, но это большая проблема
Диффи - это всегда локальная генерация секретного ключа, если кто помнит
Даже если Диффи - сервер-бейсд, закрытый ключ для данных никуда из телефона не уходит

В случае же с Ed25519 - гуляй рванина закрытые ключи по сети, хоть и в хешированном виде..
Опять же, что за хеш такой самопальный, почему не sha..
Но это еще полбеды

❗️В меголме используется один общий симметричный aes ключ на сессию, а не на каждое сообщение (как в отр/дв.хр/олм)
Что, в сочетании с группой, порождает за собой целый букет проблем
Чтобы не быть голословным, предоставим слово разработчикам:

"message can be decrypted successfully multiple times.. attacker can re-send a copy of an old message"
"пакет можно расшифровать МНОГО раз.. можно пересылать [успешно использовать] копии"

"once the key to a Megolm session is compromised, the attacker can decrypt any message.. application should periodically start a new session, with new keys shared over a secure channel"
"если ключ к сессии спалят, то расшифруют любое сообщение [в данной сессии].. приложение должно периодически начинать новую сессию, раздав новые ключи по безопасному каналу"

"Megolm ratchet relies on the availability of a secure peer-to-peer channel for the exchange of session keys"
"меголм ПОЛАГАЕТСЯ на безопасный [т.е. шифрованный сам по себе, без меголма] канал распределения ключей"

Если упростить и резюмировать эту прямую речь, то:
❗️распределение ключей они переложили на безопасный канал, что не может являться решением проблемы ну никак: ну допустим впн, но после выходного впн-сервера и до матрикс-сервера траф-то все равно пойдет ГОЛЫМ, как они предлагают обеспечивать безопасность канала на этом участке, интересно?😁
❗️обновление ключей (отрицание) они переложили на приложение.. ну допустим в riot/riotx (андроид-клиенты) это сделано, но как это сделано, как часто.. и к протоколу это вопросов не снимает в любом случае
❗️спалили ключ - спалили сессию: участников, пакеты, причастность и прочие радости
❗️пакеты можно копить, ключи можно вытащить и разломать в ретроспективе, в общем - жопа


__

Едем дальше

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

"files are encrypted using AES-CTR, which is not included in libolm. Clients have to rely on a third party library"
"файлы шифруются с помощью aes-ctr*, который не включен в библиотеку олм. Клиентам необходимо полагаться на сторонние библиотеки"

*aes-ctr - это одна из версий реализации/применения/адаптации алгоритма aes, бывают еще aes-cbc/gcm/xtr/какие-то там еще варианты, сейчас не суть, округлим до "aes - это надежно, +- в любом исполнении"

Суть тут совсем не в версии aes
Ну вы уже наверное догадались, да?😁
Что с ключами (распределение/обновление)?
C целостностью?
Если aes-ctr не входит в олм, то куда входит? в меголм? поэтому данная строчка расположена посередине меголм-раздела? или никуда не входит? как тогда применяется внутри протокола?
Кто такие клиенты - приложение или физический человек?
Какие сторонние библиотеки?

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

__

Ну и
✅звонки
все по стандарту - webrtc (srtp+dtls)

__

Итого, резюмируя матрикс в разрезе комплексного е2е:
✅текст p2p - olm (дв.хр+)
❌текст group - megolm (olm, с дырявыми ключами и без отрицания, придется обойтись пока без онлайн-сходок)
❌❓файлы - абсолютно невнятная картина, намного хуже, чем у сигнала, это тяжело назвать безопасным, тупо из-за отсутствия параметров/данных для анализа
✅звонки - webrtc

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

Теперь давайте, пожалуй, рассмотрим мой любимый отросток отр-куста:

Proteus (2016 вроде бы)
Это полноценный (т-ф-з) е2е протокол, применяется в мессенджере wire, является его собственной разработкой

Протеус сам себя называет последовательным приверженцем отр-сигнал-куста

Разберем технические аспекты, начнем как всегда с
✅текста:
✔️chacha20 - шифрование
✔️ecdh(одинарный вроде)+prekeys+hmac - ключи
✔️hmac+sha256 - mitm
✔️1 пакет - 1 ключ - отрицание

Отличий от собратьев по отр-разуму, как видно, всего два:
1. базовый алгоритм заменили с aes на chacha20, хорошо это или плохо, яхз, будем считать примерно одинаково
2. у диффи забрали два прохода и оставили ему один - базовый, классический, но все так же на кривых и на сервере, опять же, хорошо/плохо.. ну наверное чуть похуже - 3 же больше чем 1😁

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

Едем дальше, там интереснее:
✅файлы
✔️шифрует - aes-256
✔️хеш - sha256

Что с ключами, спросите вы (и правильно сделаете, умнички мои🤗)
Забегая вперед, скажу, что по обновлению (отрицание) все ровно и все просто: новый файл - новый ключ
Но тут гораздо интереснее выглядит картина по согласованию/распределению ключа, работает это так:

1. протеус берет этот одноразовый аес-ключ
2. добавляет к нему вычисленный хеш
3. воспринимает обоих как текст (чем они и являются)
после чего что? правильно
4. шифрует весь сопутствующий текст (ключ+хеш+мета) по е2е протоколу протеус
5. высылает изначальный файл двумя шифрованными пакетами, один из которых (ключ/хеш/мета) зашифрован е2е протеусом, как обычное сообщение грубо говоря

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

Еще для наглядности можно сказать так:
вы бы хотели, чтобы содержание вашей переписки было защищено полноценным е2е протоколом, или одного хеша было бы достаточно?😁
Почувствуйте разницу, как говорится

Итого, протеус-файлы - это aes256+sha256+proteus+одноразовые ключи

Неплохо-неплохо

Едем дальше
✅звонки
и тут протеус может удивить (но не сильно, это же звонки😁)
Стандартное srtp+dtls здесь используется опционально, когда звонок совершается телефон-комп
Если же звонок - телефон-телефон, то вместо dtls, для согласования ключей используется некий KASE.. что это такое информации не особо много, если не сказать, что ее вообще нет, но полагаю это тоже некий серверно-асимметричный вариант, что, в целом, никакой разницы по сравнению с dtls не образует

Удивил нас протеус другим, а именно тем, что дополнительно шифрует этот dtls/kase слой (транспортный, так называемый).. чем? правильно, протеусом

Ну просто душка, вы не находите?😁

__

Подведем протеус-итог:
✅текст - proteus (вариация на тему дв.хр)
✅файлы - aes256+sha256+proteus (оригинальное, а главное надежное решение)
✅звонки - srtp+dtls/kase+proteus (пока единственный, кто хоть что-то предпринял с шаткостью базовой конструкции е2е-звонков)

Полагаю, причины моих симпатий к wire теперь очевидны и для вас, мои золотые

Ну что, из реальной части отр-куста, осталось всего два представителя/отростка

Многого о них не скажешь, но пойдем по порядку

Omemo (2015)
Cобственно, это зеркальная - 1в1 - реализация протокола двойного храповика сигнала, но на рельсах жабы (xmpp)
На википедии написано, что в '16 году омемо отказался от двойного храповика сигнала и перешел на олм от матрикс (нихуя кардинальные перемены😂)
Ну а уже на сайте самого омемо (т.е. xmpp, ибо это одна организация) сказано, что в '17 году он отказался от олм обратно в пользу сигнала (попахивает биполярочкой)

В целом, можно сказать что это надежно, даже надежнее отр, по общим внешним признакам

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

__

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

Session (2020) (бывший loki messenger какой-то)
Бегло пробежавшись, могу заявить ответственно: выглядит весьма перспективно, и речь даже не столько о е2е-протоколе сейчас, а в целом, о концепции:
декларируемый тру-децентрал, с понятным опенсорсом, с понятным нормальным открытым протоколом, и сверху еще какие-то навороты в виде блокчейна и тора (куда ж без него😁)

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

Но сегодня мы обсуждаем е2е, поэтому обратимся к шифрованию этого самого сейшна
А тут никаких сюрпризов вообще, они тупо используют протокол сигнала, ничего в нем не меняя по шифро-сути, за исключением обеспечения децентральности
Типа преключи у них не выгружаются по 100 штук на сервер, а как-то аккуратненько отправляются потенциальному собеседнику в качестве запроса, после чего тот должен подтвердиться, и это образует сессию..
Для меня осталось не очень ясным, как именно это работает, точнее при чем здесь преключи, если это самое обычное одноразовое асимметричное распределение
Из этого вытекает логичный вопрос: если такое распределение происходит только один первый раз при первом коннекте aa и bb, то что тогда с доставкой в офлайн, а главное - обновлением ключей?
Сессии какие-то.. сессии это плохо, должно быть: 1 пакет - 1 ключ, как мы помним

Впрочем, возможно (и скорее всего) это я чета недопетрил, т.к. сервера-то у них в протоколе присутствуют, что видно и по репозиторию, где лежат: notification-server/group-server/storage-server/file-server, и по всяким описаниям самого сейшн протокола
Кстати, сервера, при этом, похоже действительно распределены, т.к. в описании говорится о неком списке промежуточных доверенных сейшн-нодов (серверов), через которые вся коммуникация и реализуется, собственно
Т.е. получается много разных серверов, а не один центральный
И
Это выглядит очень круто в рамках нашего "владельца/разработчика"
Я бы даже сказал что это тру-децентрал, причем не требующий "нашего сервера" да и "нашего сейшна" в принципе
Такой, тру-децентрал из коробки, что конечно и подкупает и заставляет сомневаться..
Ладно, будем посмотреть еще по сейшну в общем
Что же касается его е2е аспекта - получается обычный сигнал, с какими-то изменениями в преключах