Есть, конечно, различия на уровне алгоритмов шифрования, но принципиальная разница в балансе usability<->secure: Либо заставляем пользователя задумываться и делать лишние действия каждый раз при обмене ключей, либо пользователь становится уязвим.
В плане алгоритмов — у вайбера/вотцапп — асимметричное шифрование и пересылка открытых ключей через сервер, у телеграмма для секретных чатов — симметричное шифрование и генерация/обмен ключей с помощью Diffie–Hellman
Про момент «end-2-end» Для всех чатов есть маленький нюанс. Я пару раз поднимал этот вопрос. Например вот здесь:https://habrahabr.ru/company/bringo/blog/339224/
TLDR; Я считаю, что подход tg здесь лучше, чем у вайбера и прочих и вот почему:
Общая для всех мессенджеров вводная:
Ключи для e2e генерируются на стороне клиента. Публичная часть ключа через сервер передается собеседнику.
В этот момент сервер (или кто-либо скомпроментировавший канал) может применить MITM атаку и сгенерировать на своей стороне еще две пары ключей.
Поэтому все мессенджеры предоставляют пользователям возможность убедиться, что ключи никто не подменил в момент генерации. Обычно это предполагает, что собеседники просто встретятся и сравнят некие картинки или по другому, защищенному каналу обменяются отпечатками ключей. Теперь различия:
Во всех мессенджерах, которые предоставляют «e2e для всех чатов» предусмотрена возможность отправить с сервера на клиенты сообщения «повторите процедуру обмена ключами», это технически необходимо, потому что иначе пользоваться приложением будет дико неудобно. На всех мессенджерах, кроме телеграмма, такая перегенерация ключей происходит прозрачно для пользователей. Т.е. если ты хочешь быть уверенным, что тебя не подслушивают — будь любезен регулярно посматривать, а не поменялся ли отпечаток ключа для данного чата.
У телеграмма обмен ключами происходит в момент создания секретного чата. Перегенерации ключей нет. Хочешь новый ключ — начинай новый секретный чат. Это дико неудобно, но ничего не происходит прозрачно и незаметно для пользователей.
Ну, если мы хотим отбросить информацию о хиральности, то достаточно все деревья сортировать слева направо — это минимизирует запись, да.
Я бы сказал максимально минимизирует — достаточно запомнить номер разряда, где кончаются единицы и начинаются нули.
Но в большинстве случаев насколько я знаю, эта информация имеет значение…
Ошибся в расчетах.
Просто в голове засели сбалансированные бинарные деревья
Есть способ хранения бинарных деревьев в массиве:
Хранится как:
Для отображения только топологии этот массив можно представить в виде бинарного вектора. (1 — есть узел, 0 — нет узла)
Но для разреженных деревьев будет дико неэффективно.
Тут двоичные деревья
Их хранят в массивах
Если именно топологию дерева кодировать (без payload в узлах), то достаточно по биту на каждый возможный узел/лист: 2^2^N (Где N — глубина дерева)
Завершающие нули можно отбросить.
Dynamic proxy на то и dynamic, что они создаются на лету, в рантайме. На момент компиляции может не быть информации о том, какой класс мы будем проксировать.
А потом разворачивается и уходит в обратную сторону. Потому что ему не нужно за дверь, ему нужно, чтобы человек встал с кресла открывать дверь. Кресло свободно, можно его занять.
Ну это мой так делал какое-то время.
Ну hive-mind, управляющий двумя роботами вел одного из них в нужную точку, получил от него информацию о невозможности пройти. Оценил обстановку. Подвел второго на помощь. (это если никто нам ничего не втирает)
На самом деле разница только в том, что обработка данных идет где-то вне робота.
Хотя после просмотра видео сложилось впечатление, что за кадром стоят два человека и управляют роботами. Да и сами BD вроде нигде не заявляют, что роботами управляет AI
Т.е. может работать как firewall?
В плане алгоритмов — у вайбера/вотцапп — асимметричное шифрование и пересылка открытых ключей через сервер, у телеграмма для секретных чатов — симметричное шифрование и генерация/обмен ключей с помощью Diffie–Hellman
TLDR; Я считаю, что подход tg здесь лучше, чем у вайбера и прочих и вот почему:
Общая для всех мессенджеров вводная:
Ключи для e2e генерируются на стороне клиента. Публичная часть ключа через сервер передается собеседнику.
В этот момент сервер (или кто-либо скомпроментировавший канал) может применить MITM атаку и сгенерировать на своей стороне еще две пары ключей.
Поэтому все мессенджеры предоставляют пользователям возможность убедиться, что ключи никто не подменил в момент генерации. Обычно это предполагает, что собеседники просто встретятся и сравнят некие картинки или по другому, защищенному каналу обменяются отпечатками ключей.
Теперь различия:
Во всех мессенджерах, которые предоставляют «e2e для всех чатов» предусмотрена возможность отправить с сервера на клиенты сообщения «повторите процедуру обмена ключами», это технически необходимо, потому что иначе пользоваться приложением будет дико неудобно. На всех мессенджерах, кроме телеграмма, такая перегенерация ключей происходит прозрачно для пользователей. Т.е. если ты хочешь быть уверенным, что тебя не подслушивают — будь любезен регулярно посматривать, а не поменялся ли отпечаток ключа для данного чата.
У телеграмма обмен ключами происходит в момент создания секретного чата. Перегенерации ключей нет. Хочешь новый ключ — начинай новый секретный чат. Это дико неудобно, но ничего не происходит прозрачно и незаметно для пользователей.
Я бы сказал максимально минимизирует — достаточно запомнить номер разряда, где кончаются единицы и начинаются нули.
Но в большинстве случаев насколько я знаю, эта информация имеет значение…
Это в смысле деревья:
и
равны?
Или я чего-то не понял?
Я как раз рассмотрел только простые оптимизации — удаление завершающих нулей и первой единицы.
Просто в голове засели сбалансированные бинарные деревья
Есть способ хранения бинарных деревьев в массиве:
Хранится как:
Для отображения только топологии этот массив можно представить в виде бинарного вектора. (1 — есть узел, 0 — нет узла)
Но для разреженных деревьев будет дико неэффективно.
Их хранят в массивах
Если именно топологию дерева кодировать (без payload в узлах), то достаточно по биту на каждый возможный узел/лист: 2^2^N (Где N — глубина дерева)
Завершающие нули можно отбросить.
Хотя не уверен, что к EDGE его не прикрутишь
(https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/transform)
Теоретически скрипты бы должны не работать.
SVG_Security
«Зависимость загрузки сервиса в зависимости от времени», итп.
Ну это мой так делал какое-то время.
На самом деле разница только в том, что обработка данных идет где-то вне робота.
Хотя после просмотра видео сложилось впечатление, что за кадром стоят два человека и управляют роботами. Да и сами BD вроде нигде не заявляют, что роботами управляет AI