#web_crypto_api — Public Fediverse posts

После прочтения сжечь. Как устроен zero-knowledge сервис, где сервер не видит ключ

Привет! Задача возникла банальная: нужно передать коллеге пароль, API-ключ или конфиг. Телега — не хочется, почта — тем более. Существующие решения от OneTimeSecret до PasswordPusher и прочих — либо закрытый код и доверяй на слово, либо требуют своего сервера. Одни требуют регистрации, другие — напичканные всем подряд комбайны. Захотелось сделать так: открытый код, шифрование в браузере, сервер физически не может прочитать содержимое и, разумеется, бесплатно. Так появился BurnAfterRead — self-destructing E2E encrypted drops на Cloudflare Workers. Полюбопытствовать

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

#информационная_безопасность #cloudflare #open_source #web_crypto_api #zeroknowledge #aesgcm #security #privacy

Я открыл боевую базу своего clipboard-sync, чтобы показать, что он знает о вашем пароле. Ответ: ничего

Скопировали пароль от прода и синхронизировали его между ноутбуком и телефоном. Где он теперь лежит и кто может его прочитать? Я сделал сервис, где честный ответ — «нигде в открытом виде и никто, включая меня». И сейчас покажу строку из живой базы, чтобы это доказать. Это первая статья про Copy Sync — приватный кроссплатформенный обмен буфером обмена. Я не собираюсь его вам продавать. Я хочу разобрать одну инженерную задачу: как построить сервер, которому физически нечего у вас украсть , даже если им завладеет кто-то злой — включая меня самого. Весь крипто-код открыт, и проверить меня можно по ~70 строкам, а не по обещаниям.

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

#endtoend_шифрование #E2EE #zeroknowledge #X25519 #AESGCM #HKDF #Web_Crypto_API #синхронизация_буфера_обмена #NestJS #приватность

Я реализовал 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

12 слов вместо номера телефона: как мы сделали мессенджер невидимым для файрволов

BIP39 вместо номера телефона, ECDH P-256 + AES-256-GCM, non-extractable CryptoKey, трафик неотличимый от HTTPS. Как это устроено, что сломалось в процессе и почему некоторые решения были болезненными.

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

#e2ee #мессенджер #шифрование #bip39 #web_crypto_api #pwa #seed_phrase #приватность #dpi #typescript