Миссия выполнима: Как подружить Max и E2E

[anzay911]

Может, вместо стеганографии base64 с рандомными пробелами?

[dartraiden]

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

[Raegdan]

Что бейс64, что псевдокитайский очень легко детектить чуть ли не регуляркой. Лучше что-то вроде такого алгоритма вшить. Да, оверхед большой, но для текстовой переписки в принципе сойдет.

[me0wkie]

Спасибо за алгоритм, адаптировал и добавил в клиент!

[AlexKniga]

В ссылке https://github.com/kulikov0/whitelist-bypass в адресе потеряна последняя буква.

[Dreams_and_magic]

Можно ещё сделать как у Каганова, традиционную стеганографию:)

https://lleo.me/dnevnik/2026/04/01_max

[me0wkie]

Да, неплохо 😅

[Paris_Null]

Интересный эксперимент. Вопрос по архитектуре: вы храните ключи локально на устройстве или есть какой-то обмен через сервер? Если ключи только на клиенте — что происходит при переустановке приложения или смене устройства? Без механизма резервного копирования это довольно жёсткий UX для обычного пользователя, даже если криптография корректная.

[me0wkie]

На днях обновил схему, теперь есть 3 слоя: обфускация (стеганография), общий пароль и сам ChaCha20 из статьи. У сообщений может быть разная их комбинация

Если использовать только обфускацию и пароль, то резервного копирования не надо (если обфускация со словарем, то его главное не потерять)

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

Вообщем, да — при переустановке ключи теряются, и для секретного чата это нормально