#webcrypto — Public Fediverse posts

Как я написал E2EE-мессенджер на Spring Boot и WebCrypto — и почему сервер не видит сообщения

Привет, Хабр. Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом. В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза “end-to-end encryption”? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства? Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger. Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои. Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать. В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге. Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

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

#E2EE #мессенджер #Spring_Boot #X3DH #криптография #WebSocket #Java #шифрование #Signal_Protocol #WebCrypto

Feedback gezocht op:
→ Protocolontwerp & dreigingsmodel
→ Bekende beperking: nog geen Double Ratchet
→ Side-channel analyse

Whitepaper + demo: paramant.vercel.app

#PostKwantum #Cryptografie #MLKEM #PeerReview #InfoSec #WebCrypto

Парольная защита статичной HTML-страницы на JS

Обычно парольная защита производится через веб-сервер, который проверяет пароль и выдаёт контент. Стандартный способ: .htaccess и htpasswd . Но что, если нужно выложить зашифрованную веб-страницу и файлы на публичном хостинге, где у нас нет контроля над сервером? Эту проблему решают инструменты StatiCrypt и Portable Secret . Для шифрования HTML перед публикацией StatiCrypt использует AES-256 и WebCrypto, а расшифровка происходит с помощью ввода пароля в браузере на стороне клиента, как показано в демо (пароль test ). StatiCrypt генерирует статическую страницу, которую можно безопасно заливать на любой хостинг, в том числе бесплатный сторонний хостинг, такой как GitHub Pages.

https://habr.com/ru/companies/globalsign/articles/868780/

#StatiCrypt #AES256 #WebCrypto #парольная_защита #PBKDF2 #Portable_Secret #шифрование_файлов

id like to share some details about how my app works so you can discover/give me feedback on my app. id like to have wording in my app to say something like "most secure chat app in the world"... i probably cant do that because it doesnt qualify.

https://github.com/positive-intentions/chat

https://positive-intentions.com/blog/introducing-decentralized-chat

im not an expert on #cyberSecurity. im sure there are many gaps in my knowlege in this domain.

using #javascript, i initially created a fairly basic #chatApp using using #peerjs to create #encrypted #webrtc #connections. this was then easily enhanced by exchanging additional #encryption #keys from #cryptography functions built into browsers (#webcrypto api) to add a redundent layer of encryption. a #diffieHelman key #exchange is done over #webrtc (which can be considered #secure when exchanged over public channels) to create #serverless #p2p #authentication.

- i sometimes recieve feedback like "javascript is inherently insecure". i disagree with this and have #openedSource my #cryptography module. its basically a thin wrapper around vanilla cryptography functions of a #browser (webcrypto api).

- another concern for my kind of app (#PWA) is that the developer may introduce malicious code. this is an important point for which i open sourced the project and give instructions for #selfhosting. selhosting this app has some unique features. unlike many other #selfhosted #projects, this app can be hosted on #githubPages (instructions are provided in the readme). im also working towards having better support for running the index.html directly without a static server.

- to prevent things like browser extensions, the app uses strict #CSP headers to prevent #unauthorised code from running. #selfhosting users should take note of this when setting up their own instance.

- i received feedback the #Signal/#Simplex protocol is great. completely undertsandable and agree, but wonder if im reducing the #complexity by working with #webrtc. while it has its many flaws, i think risks can be reasonable mitigated if the #cryptography functions are implemented correctly. (all data out is #encrypted and all data in is #decrypted on-the-fly)

- the key detail that makes this approach unique, is because as a #webapp, unlike other solutions, users have a choice of using any #device/#os/#browser. while a webapp can have nuanced #vulnerabilities, i think by #openSourcing and providing instructions for #selfhosting and instructions to #build for various #platforms, it can provide a reasonable level of #security.

i think if i stick to the principle of avoiding using any kind of "required" service provider (myself included) and allowing the #frontend and the peerjs-server to be #hosted #independently, im on track for creating a #chatSystem with the "fewest moving parts". i hope you will agree this is true #p2p and i hope i can use this as a step towards true #privacy and #security. #security might be further improved by using a trusted #VPN.

while there are several similar apps out there like mine. i think mine is distinctly a different approach. so its hard to find #bestPractices for the functionalities i want to achieve. in particular #security practices to use when using #p2p technology.

(note: this app is an #unstable, #experiment, #proofOfConcept and not ready to replace any other app or service. It's far from finished and provided for #testing and #demo purposes only. This post is to get #feedback on the progress to determine if i'm going in the right direction for a secure chat app)

@kkarhan

thanks for the reply! far from being discouraged, i appriciate your engagement. i will try to be reasonably brief in my reponse to your points and give a general update on progress and objective.

> scout out existing solutions

i have seem similar #webapp implementation, i think so far for "that kind" of chat app, the chat app is able to demonstrate similar basic functionality. for a wider adoption, the user interface needs to be more appealing, but i think its important to have a working proof-of-concept first. the project is specifically aiming to be a #javascript #localFirst #webapp.

a couple notable similar implementation to mine are:
- https://github.com/cryptocat/cryptocat
- https://github.com/jeremyckahn/chitchatter
(im sure there are many more, but i think my approach is yet different and unique to the ones i've come across.)

> DO NOT DIY ENCRYPTION!

this is indeed a reccomended practice i have seen several times. here is a previsous reddit post on the matter: https://www.reddit.com/r/cryptography/comments/1cint8h/what_are_your_thoughts_on_subtlecrypto_vs_wasm ... tldr; the underlying implementation provided by the browser is the best way to go. i have implemented the #encryption using the #webcrypto #api. i aim to not use a library for this.

i generally try to word things in a way that users can provide feedback on features. the app is still in a very early stage, but has a reasonable amount of features. im generally open to requests and questions.

> minimum viable product

what you see as the chat app is also the #minimum #viable #product. i think its sufficiently demonstrates the basic functionality of a chat app. i think the next step is to make the app more stable and user friendly.

those other apps youve mentions ive come across before. what sets my approach apart is that mine it's purely a webapp. with what id like to describe as #p2p #authentication over #webrtc, im able to remove reliance on a backend for #authenticate #data #connections. in some cases, bypass the internet (wifi/hotspot). while there are several ways to #selfhost, in this approach of a #javascript implementation, im able to store large amounts of data in the browser so things like images and #encryptionKeys can be #selfhosted" in the browser. while this form has nuanced limitations, it also has interesting implications to security and privacy.

there are many nice features from the different apps you mentioned and i think i have some unique features too. the bottle neck in this project is that i dont put in enough time to the app.

> feel free to slowly ibtegrate them.

this is basically already my approach to get the app to where it is now.

thanks for the luck, take care and i hope you stay tuned for updates.