#endtoend_encryption — Public Fediverse posts on home.social

Habr @[email protected] · 2026-06-24 · 12:12 UTC

Два месяца спустя. Что я понял, пока пытался сделать E2EE-мессенджер

Два месяца назад я опубликовал статью про свой pet-проект — E2EE-мессенджер. Честно говоря, я не ожидал, что она вызовет такой интерес. Прилетели комментарии, замечания, вопросы и довольно полезная критика. Где-то меня поправили по делу. Где-то заставили пересмотреть решения, которые мне самому на тот момент казались нормальными. И, что самое приятное, часть вещей, которые тогда были только в roadmap, за это время удалось реализовать. Первая часть: https://habr.com/ru/articles/1030854/ Проект: https://github.com/vaazhen/chaos-e2ee-messenger Вообще, за эти два месяца я понял одну простую вещь. Написать чат оказалось не так сложно. Написать E2EE-мессенджер — уже сложнее. А вот понять, почему Signal делали столько лет, оказалось совсем другой историей. Сначала кажется: ну есть же документация, есть X3DH, есть Double Ratchet, есть WebCrypto, есть статьи, есть спецификации. Осталось просто аккуратно всё собрать. Примерно в этот момент где-то вдалеке начинает смеяться инженер из Signal. Сразу оговорюсь: chaos messenger — это не замена Signal и не “готовый безопасный мессенджер”, а open-source pet-проект, на котором я разбираюсь, как E2EE-системы устроены изнутри.

https://habr.com/ru/articles/1051406/

#E2EE #endtoend_encryption #Double_Ratchet #X3DH #WebCrypto #Spring_Boot #React #Electron #PostgreSQL #Redis

#redis #postgresql #electron #react #spring_boot #webcrypto

Habr @[email protected] · 2026-06-09 · 05:52 UTC

Я не хотел, чтобы WeTransfer читал мои файлы, и написал хранилище, которое не доверяет само себе

Каждый раз, когда нужно передать кому-то файл или пароль, выбор бесит: WeTransfer и аналоги видят всё, почта и телеграм хранят файл в плейнтексте вечно, PrivateBin только для текста. Хотелось простого: бросил файл, получил ссылку, а сервер физически не может его прочитать. И чтобы сервер был мой. Так появился share·me, self-hosted сервис, который шифрует файлы и текст прямо в браузере (AES-256-GCM), а ключ кладёт в URL-фрагмент, который браузер никогда не отправляет на сервер. Внутри: Rust/axum, Next.js, потоковое шифрование больших файлов и пара граблей, на которых я споткнулся. Показать, как это устроено

https://habr.com/ru/articles/1045242/

#endtoend_encryption #шифрование #selfhosted #zeroknowledge #AES256GCM #Rust #Nextjs #обмен_файлами

#обмен_файлами #nextjs #rust #aes256gcm #zeroknowledge #selfhosted

Habr @[email protected] · 2026-05-11 · 16:12 UTC

Я реализовал Double Ratchet в React Native мессенджере. Разбор протокола и кода

В прошлой статье про трёхуровневый кэш сообщений я уже упоминал, что делаю мессенджер ONEMIX на React Native. Базовое E2E у меня было простое: ECDH P-256 для обмена ключами при первом контакте, AES-GCM для шифрования каждого сообщения общим секретом. Это работает, но имеет одну проблему: общий секрет один на всю переписку . Если у одной из сторон скомпрометируют приватный ключ — все сообщения за всё время превращаются в открытый текст. Это называется отсутствием Perfect Forward Secrecy (PFS). И это значит, что человек, к которому в руки попадёт твой телефон через год, может прочитать переписку из прошлого года. WhatsApp, Signal, и серьёзные части Telegram давно используют другую схему — Double Ratchet — которая ключи переизбретает заново на каждом сообщении. Так делают потому, что любой ключ компрометируется в один момент времени, и компрометация не должна давать доступа ни к прошлому, ни к будущему. Я реализовал Double Ratchet с нуля для ONEMIX. В этой статье разберу:

https://habr.com/ru/articles/1033830/

#double_ratchet #signal_protocol #e2e #endtoend_encryption #react_native #криптография #мессенджер #ecdh #hkdf #web_crypto_api