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

По теме же е2е нам осталось рассмотреть всего 3 протокола, которые не родственны отр/сигналу и пошли своим путем (весьма условно, как обычно😁)

Но это уже не сейчас, силы покинули..

Всех обнял, tbc

Едем дальше, малята, знаю, вы скучали😘😁

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

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

Поэтому едем дальше

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

Речь идет о

NaCl (2008)
Это не совсем е2е-протокол, строго говоря
При этом сама базовая соль (nacl - это поваренная соль, если кто помнит) оказалась не очень качественной в практическом смысле, и служила скорее неким манифестом, нежели реальным инструментом, по крайней мере 1ая версия

Перед тем как говорить об особенностях этого протокола, давайте сначала глянем на базовые параметры:
✔️aes128 или aes256 или salsa20 или xsalsa20 - шифрование
✔️crypto-box или Ed25519+sha512 или хешированный ecdh - ключи
✔️sha256или512 или hmac+sha256или512 или poly1305 - mitm
✔️1 пакет - 1 ключ - отрицание
при этом
или✔️crypto-box - это сразу ключ+шифр+mitm - ecdh+xsalsa20+poly1305
или✔️crypto-secretbox - это сразу шифр+mitm - xsalsa20+poly1305 (как в этом случае распределяется общий секретный ключ, для меня осталось загадкой.. возможно Ed25519+sha512..)

Итак
Что бросается в глаза:
1. большой выбор аналогов: или или или
2. крипто-(сикрит)боксы какие-то


Разберемся😁

Соль - протокол, созданный как бы максимально универсальным: максимально адаптированным под различные языки программирования, максимально накаченным достойными алгоритмами/протоколами
При этом сами создатели топят за sals'y вместо aes, мотивируя это скоростью, что выразилось в их крипто-боксе, в который можно сразу запаковать сообщение/ключ/хеш, и это будет 1 пакет, либо как-то с помощью него распределить ключи, где сообщение будет являться секретным ключом, видимо.. хз, точнее сказать затрудняюсь😁
Ну и вариация на тему - крипто-сикритбокс, где в одном пакете пойдет сообщение/хеш, что в этом случае с ключами тоже не очень ясно.. возможно любая из доступных опций..

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

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

Из всего вышесказанного можно вывести следующее:
NaCl (равно как и соду) - нельзя назвать протоколом е2е шифрования
Это программные библиотеки, модули, набор практик
Как эти практики, собственно, практикуются - в каждом отдельном случае смотреть надо ОТДЕЛЬНО
Например, 1ключ-1пакет - это хоть и не модуль, а настройка, но настроить-то ее можно по-разному, а можно ведь вообще не настраивать..

К чему это я

В нашем рейтинге соль представлена 2 участниками:
Вышеупомянутый Tox, подробно рассматривать который мы не будем в силу мертвого юзабилити
А также широко известная в узких кругах - Threema, реализацию соли в которой мы также не будем рассматривать, чуть позже станет ясно почему

Ну и осталось нам 2 протокольчика
Они, можно сказать такие.. моно-протоколы, т.е. протокол-мессенджер, и все - больше нигде он не применяется/не развивается/не плодится/итд
Такие типа сами-с-усами (ох, лучше б не выебывались🤦‍♂️)

Первым давайте рассмотрим

Wickr (2015)
Напоминаю, дата указана к протоколу, само приложение викр на 3 года старше - 2012

Итак, что же это за протокол такой интересный.. необычный и отдельно стоящий?😁

Погнали:
✔️aes256 - шифрование
✔️ecdh+sha256 - ключи
❗️tls - mitm (серьезно?😂)
✔️пакет-ключ - отрицание

А столько шуму было, викр-викр..
Я недаром отрезал его от отр-куста, хотя сходство налицо, разве что викр зачем-то сильно поставил под сомнение свой титул е2е:
tls для подтверждения целостности? это не шутка? целостность будет подтверждаться сервером викера? т.е. от человека-посередине нас будет защищать человек-посередине?
Оригинальное решение😂

Но викр и сам отрезался от двойного храповика (т.е. сына отр, если кто забыл):

"we’ve spent..effort analyzing (and improving on) the DR.. Despite this..we..opted for a decidedly different approach"
"мы потратили много сил анализируя (и УЛУЧШАЯ) дв.хр..но в итоге выбрали кардинально другой подход"

Мда уж.. улучшили неебаться просто, а подход в итоге действительно кардинально отличается..🤦‍♂️

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

Вот тебе и Wickr
И это был только текст
файлы там походу тупо tls, ну а звонки меня вообще слабо интересуют в такой конфигурации😂

Ну и на десерт, малята, я вам приготовил что?😏
Все верно, тгшечку, родненькую
Рассмотрим крутой протокол крутого павлика? а точнее его братишки кольки

Не побоюсь этого слова, погнали:

MTProto (2013)

Начнем с того, что е2е работает ИСКЛЮЧИТЕЛЬНО В СИКРИТ-ЧАТАХ и звонках
❗️Обычные, или клауд-чаты, как они это называют, шифруются тоже с помощью мтпрото, но не е2е, а е2сервер2е, так что в принципе уже похуй чем оно там шифруется

Теперь давайте глянем как именно то самое е2е работает:

❌текст:
✔️aes256 - шифрование
❗️dh (cамый стандартный, вот того '76года, ретро😂) - ключи
✔️sha256 - mitm
❗️1 ключ на 100 сообщений/на неделю - отрицание

❌файлы:
✔️aes256 - шифрование
❗️ключ передается вместе с пакетом, под "защитой" md5-хеша🤦‍♂️..  а че на 2 просто не умножили?
❗️по целостности вообще ничего
❗️зато здесь типа 1 ключ - 1 файл, но он НЕ ОДНОРАЗОВЫЙ, а с учетом md5-защиты - правдоподобное отрицание лучше бы придумать себе заранее - перед отправкой файла

Чтобы сформировать целостную картину по файлам, предоставим лучше слово самому павлику:

"The encrypted contents of a file are stored on the server in much the same way as those of a file in cloud chats"

"Зашифрованный [е2е в сикрит-чате] файл хранится на сервере ВО МНОГОМ ТАКИМ ЖЕ ОБРАЗОМ как и файл из клауд чата [псссс, павлик ты очень палишься]"

"encrypted files can be forwarded to other secret chats..to avoid saving the same content on the server twice"

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

Могут быть пересланы = могут быть прочитаны/расшифрованы ЕЩЕ РАЗ = ключ не умер = пиздец
Дубли на сервере тебя беспокоят? А нахуй ты вообще хранишь это все, уебище ты лесное? Раз в неделю почистить сервер - не приходило в голову? Или ценную информацию удалять жалко?

❌звонки
✔️dh + sha256 - ключи (почему на текст было так не сделать..?)
❗️голосовые пакеты разбиваются на маленькие кусочки и шифруются мтпрото.. что бы это ни значило😁
❓...
✔️ну полагаю, 1 звонок - 1 ключ, хотя это уже не принципиально

И здесь павлик сумел красиво пернуть в лужу..
srtp+dtls - далеко не образец для подражания, конечно, но это..

__

Даже не знаю, требуется ли здесь какое-то резюме..
Ну разве что в очередной раз заключить, что мтпрото - это и близко не е2е
Викр уж куда больший е2е, со своим тухлым tls'ом

Так ну че, мои золотые
Вот мы и пробежались по всем актуальным алгоритмам и протоколам шифрования на конец июля '20

Но перед тем, как перейти уже к следующим параметрам/критериям, отвечающим на 1️⃣❓возможен ли..в принципе?, скажем финальное слово о е2е-шифровании:

Все, что мы разобрали по части шифрования к настоящему моменту, все алгоритмы и протоколы, которых коснулись, все эти базовые rsa/aes/salsa-chacha/diffihellman/hmac-sha-polly/кривые-косые-прямые и проистекающие из них более сложные otr/signal(дв.хр)/olm/megolm/proteus/nacl/wickr/srtp/(d)tls/webrtc/и даже mtproto - все они имеют кое-что общееобщее

Именно это общееобщее и давало возможность обсуждать все это в принципе
Именно это общееобщее и наделяет все наши шифро-рассуждения смысловой нагрузкой
Именно это общееобщее и является одним из решающих факторов при оценке безопасности канала
И
Отсутствие именно этого общегообщего делает любое исследование, а даже и праздное рассуждение - АБСОЛЮТНО НЕРЕЛЕВАНТНЫМ

Уже догадались, мои умненькие?😘

Да, все верно - ОТКРЫТОСТЬ
Все эти протоколы/алгоритмы - ОТКРЫТЫЕ
Тот самый opensource, мы уже касались этой темы вскользь

Что же значит opensource применительно к е2е шифрованию?
Все очень просто:
✔️во1 сам код: "можно скачать/собрать/изменить/проверить/использовать" - т.е. применить такой протокол в своем мессенджере, например
✔️во2 описание: подробно и занудно расписано как, когда и при каких условиях это работает, почему так, часто - математические формулы самого шифрования. Как правило, описание реализовано в виде так называемой whitepaper, но не всегда и необязательно: бывают описания внутри репозиториев с кодом, во всяких readme и прочих подводках, но так или иначе какое-то описание к протоколу должно быть, хотя зачастую информации явно не хватает (сигнал-по-файлам/матрикс-по-файлам/мтпрото-по-звонкам)

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

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

Опенсорс - это то, что идет по умолчанию, goes without saying
Опенсорс - золотой стандарт безопасности, эталон в палате мер и весов

Но окружающая реальность далекоооо не наполнена эталонами, как нам всем хорошо известно

Поэтому

Мессенджер заявляет о том, что он безопасен?
У него на сайте/в плей сторе/в пресс-релизе/в уебанском рейтинге/в блоге разработчика сказано что все шифруется е2е?

Это полная хуйня
Это не значит абсолютно ничего
Покажите:
✔️сам код (разговор пока только про код протокола, а не приложения/сервера, об этом дальше)
✔️описание (whitepaper или readme или хоть что-нибудь)

В этой связи
Если, например, vipole посвятила целую страницу на своем сайте, чтобы проехаться нам по ушам рассказать о своем чудесном шифровании, но при этом не представила ни строчки кода - идет сразу нахуй, тут не о чем разговаривать в принципе
Ну я не знаю, давайте еще обсудим безопасность viber'a, он тоже говорит, что е2е😁 да еще и по сигнал-протоколу (типа опенсорс) - неужто это хуже виполиной?😂

Так что весь этот детский сад оставляем для соответствующего потребителя

Рассуждаем рационально:

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

🟢если протокол (код) открыт, то за сам этот факт - положительный балл, но небольшой совсем
Зато этот факт хотя бы дает возможность рассмотреть такой протокол
Рассматривать будем по трем параметрам (типам соединений):
✅текст
✅файлы
✅звонки
Каждый параметр оцениваем отдельно: положительно, отрицательно или нейтрально - если протокол не предусматривает данный тип соединения, например жаба, где только текст
Баллы по этим параметрам тоже будут небольшие

__

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

Едем дальше
Пока мы сформулировали следующие критерии:
✔️владелец/разработчик - тру-децентрал-и-п2п (=хорошо) либо нейтрально либо проблемы
✔️е2е - opensource+протоколы (=возможно хорошо) либо закрытый код (=очень плохо)

Теперь давайте разберемся, что еще может влиять на безопасность канала

Конечно, opensource всего остального
Открытый протокол - это хорошо, но у вотсапа тоже типа внутри - открытый сигнал-протокол
Будете смеяться, у вотсапа даже whitepaper есть
Ну я смеялся, когда читал, по крайней мере😁

В случае с вотсапом, открытость сигнала, даже если он действительно так или иначе там применяется, НЕ ДАЕТ АБСОЛЮТНО НИЧЕГО

Мы не знаем применяет вотсап протокол сигнала или не применяет, как применяет, не отключает ли его на пару часов в день, на профилактику, например

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

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

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

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

Открытость кода - критически важный аспект всего предприятия
И хотя история с безголовым-браер-пиром наглядно показывает, что опенсорс опенсорсу - рознь, но также она показывает, что опенсорс - надежный метод проверки
Также, опенсорс отличается еще и видом лицензий на использование, но нас это не касается, главное чтобы можно было "скачать/собрать.."

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

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

Как бы там ни было, opensource - это хорошо, это открытое забрало, это честная игра, это большой положительный балл

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

Т.к. вы наверное помните, как я пролопушился мальца с серверной частью у тг, которая оказалась ЗАКРЫТА (оказалась она?😂😂😂)
Ну в общем, сей факт заставил разделить opensource на сервер и на клиент, т.е. оценивать по отдельности

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

Поясню:
Приложение, т.е. исполняемый файл, особенно с доступом в сеть и разрешениями на закачку в фоне и хранилище (а такое есть/выдается почти всем мессенджерам) - это потенциальная угроза не только и не столько переписке в конкретном мессенджере, а РЕАЛЬНАЯ УГРОЗА САМОМУ ТЕЛЕФОНУ и всему, что через него ПРОХОДИТ И ХРАНИТСЯ в нем

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

Отвлеклись😅
Вернемся к опенсорсу
Итак отдельно клиент(ы), отдельно серверная часть

🟢в открытом доступе - положительный балл (клиенту чуть больше)

🔴в закрытом - отрицательный балл
тут баллы (сами числа) будут абсолютно симметричны положительной альтернативе - условно либо +1, либо -1, без перегибов, но есть нюанс😏

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

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

Дальше станет понятнее, пока просто зафиксируем
__

Резюмируем по opensource
Параметр делится на два:
✔️клиентская часть
✔️серверная часть

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

Теперь рассмотрим несколько неочевидный, но тем не менее очень важный, и порой весьма наглядный параметр/критерий:

✔️Количество android разрешений
Неочевидность параметра в том, что помимо андроида существует множество других ОСей и, соответственно, клиентов конкретных мессенджеров для этих ОСей
Поэтому как нам поможет такая узкая специализация для комплексной оценки?

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

Особенность операционной системы андроид, выразившаяся в этих разрешениях - runtime permissions, помогает очень наглядно увидеть базовые требования приложения к нам:
Хочет он камеру? Контакты? Хранилище/интернет/локацию/смс?

А поскольку приложение от одного разработчика (мессенджера), то можно логично предположить, что и на других операционках (ios/win/mac) он захочет +- то же самое

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

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

Гораздо забавнее глянуть тупо на их количество
Мы как бы отвечаем для себя на вопрос:
а сколько всего он от меня хочет вообще?

Данный параметр, конечно, далеко не определяющий, оценивать будем
🟢гуд
⚪️соу-соу
🔴бед

Балл будет присуждаться по простому количественному признаку, по схеме: от 1 до 2 - гуд, от 3 до 4 - соусоу, от 5 и выше - бед
Балл будет небольшой, т.к. это все же - косвенное, но тем не менее порой весьма наглядное, интересно сравнить, приколитесь

Дальше

Теперь рассмотрим такой параметр.. сложносочиненный, скажем так
Он высчитывается ровно из уже рассмотренных параметров и не требует каких-либо внешних изысканий
Мы просто складываем параметры:
✔️е2е (во всех его аспектах)
✔️opensource client
✔️opensource server
и получаем параметр:

✔️базовый функционал

Этим параметром мы отвечаем себе на вопрос:
А что мы можем безопасно делать с помощью этого мессенджера?
Функционал недаром называется базовый, и недаром здесь замешано е2е

Как вы могли уже догадаться этот параметр будет содержать в себе 3 уже знакомых нам подпараметра:
✅текст
✅файлы
✅звонки

Этим тройным параметром мы как бы подытоживаем вообще практический смысл использования того или иного мессенджера

Подход при оценке следующий:

🟢если сложилось достойное е2е+полный opensource по какому-либо из типов соединений (т-ф-з), то такой тип соединения получает положительный балл, т.к. это можно назвать: базовый функционал присутствует, через этот мессенджер можно писать (или звонить или слать файлы)

⚪️если не сложилось, по той или иной причине: дырявое ли е2е, закрыт ли код, а равно даже и просто данный функционал не предусмотрен протоколом - как бы там ни было, мы просто считаем, что этого нет, т.е. базовый функционал по тому или иному типу соединения отсутствует
В этом случае мы не будем отнимать баллы, мы просто их не дадим, поставим 0
Нет функционала и нет, на нет и суда нет, че тут обсуждать, ругаться бессмысленно
Все косяки по безопасности были предъявлены ранее, сейчас мы просто констатируем: жив или мертв
Т.е. например жаба за файлы и звонки получит 0 точно также, как вотсап получит 0 по всему базовому функционалу
В первом случае это будет ограничение протокола, во втором - закрытый код, но в обоих случаях этим нельзя пользоваться, поэтому функционала нет, поэтому 0

Поначалу думал дополнительно-положительно окрасить данный параметр (типа там +0.5 баллов), в случае если шифрование предусмотрено по умолчанию.
Например у жабы и тг - не по умолчанию, надо что-то делать ручками, включать его как-то
А у ваера/сигнала/и даже вотсапа😂 - по умолчанию

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

Ну и всего пару параметров нам осталось, собственно

Первый из них совсем простенький, назовем его:
✔️всякие фишечки
это параметр, касающийся безопасности, но как понятно из названия - такой.. баловство
Сюда войдут всякие запреты на скриншоты, таймеры, шифрование по умолчанию опять же, анонимная регистрация, какие-то тор-приблуды, какие-то необычности, которые типа делают мессенджер безопасным
Поскольку мы уже очевидно понимаем, что совсем не это определяет безопасность, то пожалуй соберем это все в одну кучу
Сделали что-то там такое необычное классное и прикольное? Ну молодцы, небольшой балл вам присудим за такое
Но мы же все тут - взрослые люди и прекрасно понимаем, что запретом скриншота мы не решаем проблему, т.к. и текст и картинки, отображающиеся на экране нашего телефона - ХРАНЯТСЯ В ПАМЯТИ ЭТОГО ТЕЛЕФОНА, по другому не бывает😁
Не говоря уже о том, что можно перефоткать с другого телефона

Короче это все баловство, ну если постарались ребята, ну ок, балл присудим, небольшой
Не постарались - не присудим, 0 будет по этому параметру

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

Ну и пресловутое

✔️юзабилити
По данному критерию нас заботит простой человеческий вопрос:
Это работает? Сообщения доходят? Звонки проходят? Файлы отправляются? Стабильность? Аптайм? Работа в фоне?

Вот такие простые бытовые вопросы
Мессенджер помимо безопасности должен обеспечить собственно сами месседжи

юзабилити мы будем оценивать так:

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

⚪️если на вопросы выше мы отвечаем по большей части положительно (опять же в первую очередь аптайм) - это нейтральная оценка
Так и должно быть, в этом нет никакого бинома ньютона, аптайм и стабильность можно обеспечить не в ущерб безопасности и доказательства тому существуют прямо вокруг нас
Звонки/сообщения проходят, мы стабильно на связи, не танцуя с бубном вокруг телефона?
Это достойно, это хорошо, это не будет оценено отрицательно, но и плюсов тут ставить особо не за что
В данной категории допускаются легкие лаги, небольшие вылеты, подтормаживания и прочие мелкие неприятности, если они не носят системного характера и не влияют на базовый функционал
Все работает? Отлично, 0 баллов

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

Ну что, братья и сестры, подведем промежуточный итог

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

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

Итак, нас волнуют следующие параметры:

1️⃣✔️Владелец/разработчик, где
🟢хорошо - это тру-децентрал (свой "что-то") или п2п (без сервера посередине, что нежизнеспособно, как мы убедились)
⚪️нейтрально - это хз, плохого не слыхали пока
🔴плохо - это общеизвестные отрицательные факты, также настойчивые слухи

2️⃣✔️е2е-шифрование, где
🟢хорошо - это открытый протокол, позволяющий оценивать е2е по тексту/файлам/звонкам по отдельности, где каждый параметр получает 🟢/⚪️/🔴 (⚪️- в резерве, посмотрим использовать/нет)
⚪️нейтрально - тоже в резерве, пока не решил, возможно применю к вотсап-вариантам (открытый протокол/закрытый код), а возможно не буду использовать, поглядим
🔴плохо - это закрытый протокол (=нет шифрования)

3️⃣✔️opensource, client и server оцениваются отдельно, где
🟢хорошо - это код открыт
🔴плохо - это код закрыт, что помимо отрицательного балла, обнуляет базовый функционал

4️⃣✔️базовый функционал, где оценивается каждый отдельный тип соединения так:
🟢хорошо - это можно безопасно коммуницировать
⚪️нейтрально - это нельзя/невозможно безопасно коммуницировать

5️⃣✔️андроид-разрешения, где
🟢хорошо - это мало
⚪️нейтрально - это средне
🔴плохо - это много

6️⃣✔️всякие фишечки, где
🟢хорошо - это они есть
⚪️нейтрально - это их нет

7️⃣✔️юзабилити, где
🟢хорошо - это что-то крутое и стабильное
⚪️нейтрально - это все работает
🔴плохо - это не работает

__

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

​*кратенько отвлечемся😏

есть такой тг канал - вчк-огпу, многие знают наверное, такой мусорской сливной бачок: материалы уголовных дел, компроматы всякие, сливы-прогоны итд (футляр был круче, r.i.p.✊)

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

К чему это все

В данной серии они публикуют распечатки чатов.. и я все читал и пытался понять: откуда? что это за мессенджер?

т.к. там присутствуют голосовые/фотки/аудиозвонки - явно это не gsm, а какой-то мессенджер.. но какой?

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

Но одно сообщение четко указало откуда прикуп (дальше сами поймете)

Вот такое вотсап-е2е, братья и сестры, по сигнал-протоколу, между прочим😂

Так что ожидайте, скоро все будет
Рейтинг - готов, посчитан
Все - кристально
Осталось тока перевести это все в буковки😁

Ну а пока, наслаждайтесь (СКВОЗНЫМ шифрованием😂😂😂)

⬇️

​Привет, братья и сестры
Продолжим

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

И параметры - это хорошо, но еще слишком концептуально
К тому же, их - много: немудрено запутаться/что-то упустить/промахнуться с приоритетами

Следовательно
Параметры надо:
✔️стандартизировать
✔️упорядочить, в том числе связи/зависимости внутри параметров
✔️ввести единую методику оценки и подсчета (баллы)

✅создав таким образом уже по-настоящему рабочий инструмент - наглядную систему оценки, рейтинг, что-то типа скоринга в банке:
❓закинули претендента
📝разложили по косточкам
🔢обсчитали
⚠️приняли решение

И, конечно, этот инструмент/рейтинг/скоринг готов (стал бы я выебываться😌)
Хочу теперь сначала подробно разобрать:
1. как что считается
2. почему так
3. исключения/артефакты/необычности - куда ж без них😁

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

__

Начнем с простого
Все помнят "Владельца/Разработчика""Владельца/Разработчика"
Считаем так:
🟢+4 балла (tru-decentral/p2p)
⚪️0 баллов (хз)
🔴-4 балла (все плохо/ру-снг)

Решил добавить небольшое исключение:
⚪️🟢+1 балл за потенциальный tru-decentral
Такой балл получили только Riot и Session, т.к. выглядят действительно перспективно в этом отношении.. да и не только в этом😏
При этом, +1 для этих двоих ни на что вообще не влияет в рамках общего зачета, можно и забрать
Но сердцу редакции эти двое приглянулись, и мы решили их поощрить, но сугубо символически

В остальном же, параметр "владелец/разработчик" - довольно прост для понимания, баллообразование - предельно очевидно, этот параметр не влияет и не подвержен влиянию других параметров*, поэтому будем считать разобрались

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

Дальше разберем нечто более сложносочиненное - е2е шифрованиее2е шифрование

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

Чуть сложнее:
🟢+1 балл - любой открытый протокол (даже если он хуевый), после чего смотрим отдельно (1)текст, (2)файлы, (3)звонки по следующей маске:
 🟢+1 балл - надежно
 ⚪️0 баллов - не предусмотрено
 🔴-1 балл - не надежно
Итого
если е2е открытое*:
максимум можно получить +4 балла: открытый протокол (+1) и надежные текст (+1), файлы (+1) и звонки (+1)
При этом
один ненадежный тип соединения дает уже всего +2 балла (3-1)
два - обнуляют (2-2)
ну а все три - загоняют е2е в отрицательную зону -2 балла (1-3)
И все это при открытом протоколе, обратите внимание
Яркий представитель - телеграм - открытость протокола не защитила от его дырявости, и это должно быть оценено отрицательно, полагаю логика ясна

Ну а ⚪️не предусмотрено (по какому-либо из типов соединения) с его 0 баллов, думаю тоже понятно как обсчитывать

​Получается по е2е:
минимум -6
максимум +4
Как и обещал - пиздабольство наказано😁

И в общем-то выше описан исчерпывающий механизм оценки е2е шифрования
Но есть нюанс😏

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

И влияет на е2е, конечно же, открытость остального кодаоткрытость остального кода (клиенты и серверная часть)

Если клиент и/или сервер закрыт (называется proprietary - pp), то мы не можем рассматривать е2е по т-ф-з положительно
Наглядный пример - вотсап, у которого протокол типа сигнал, ну а по факту мы все знаем какое там е2е

Поэтому
При открытом е2е-протоколе и закрытом клиенте и/или сервере
за е2е
мы можем поставить +1 за открытость протокола
можем рассмотреть т-ф-з
но вместо +1 за надежный т/ф/з мы поставим 0 баллов
в остальном подсчет е2е останется прежним: не предусмотрено 0 баллов, плохо -2 балла

Сами же клиент и сервер рассматриваются максимально просто:
сервер
🟢+2 балла - открытый код - opensource - os
🔴-2 балла - закрытый код - proprietary - pp

клиент
🟢+3 балла - открытый код - opensource - os
🔴-3 балла - закрытый код - proprietary - pp
*почему клиент важнее

__
При этом
Открытый код клиента и сервера влияет не только на е2е
Но это в следующих сериях уже, утомился чет😅

Протестующие в центре Минска, по-видимому, смотрели ролики с митингов в Москве и сумели уяснить, что крики «Позор!» на силовиков особо не действуют. Поэтому пошли отбивать своих у милиции.
💁🏼‍♀️ ѣѣ
источник

так выглядят свободные люди свободной воли

и это выглядит красиво