Състоянието на издание Ad Nihilum 0.4.3 — минималистичен сервис за обмен на криптирани съобщения по принципа "прочетох — изгорих", ориентиран основно към self-hosting.
Сървърът играе ролята на глухо хранилище. Шифрирането и разшифровката се извършват единствено от клиентската страна, в браузъра (чрез AES-GCM).
Предимства
- локално шифриране и разшифроване, сървър никога не вижда ключа;
- поддръжка на допълнителен слой шифриране с парола, за която (1) сървърът не може да разбере, (2) не може да се определи по предавана връзка;
- проектът съдържа около 2200 реда сървърен код на Си и 600 реда клиентски код на JS, което улеснява одита;
- Ad Nihilum зависи само от libmicrohttpd. За генериране на QR кодове се предоставя модифицирана версия на QRCode.js;
- включени указания за бързо стартиране на локален сервиз без външен IP;
- Ad Nihilum работи и на Android, приложен е съответният скрипт за изграждане в Termux;
- еднопоточен и синхронен сървър.
Промени
Масивен редизайн
- Страниците за изпращане и получаване на съобщения са разделени, съответстващият клиентски код.
- Общият дизайн беше значително променен и коригиран с оглед на пожеланията на потребителите.
- "Прости" и локални клиенти:
- клиентските страници могат да бъдат запазени локално и използвани от file://.
Политики на браузъра
- въведен е CSP за борба с XSS;
- сървърът изпраща HSTS.
Други промени
- проектът е преименуван от Epha-ots;
- закупен е домейн adnihilum.net;
- TLS се осигурява с помощта на Let’s Encrypt, това е важно да се знае (няма пари);
- облекчена работа с файлове;
- преход към fat-пойнтери;
- поправени са дребни грешки;
- авто-jsminify и изграждане на клиентски файлове при изграждане чрез CMake.
Преглед на протокола
Генериране на три случайни стойности: ключ K, вектор за инициализация N и сол S. K — 256 бита, N — 96 бита, S — 128 бита.
Извеждане на ID от K и S чрез HKDF на базата на SHA-256.
Създайте низ от допълнителни автентификационни данни aad — това е просто низ от вида: id=ID
Ако потребителят е задал парола:
- изведете Pk от паролата и S чрез PBKDF2, SHA-256, 800000 итерации;
- една и съща сол се използва за всичко;
- шифрирайте данните с AES-GCM, използвайки ключ Pk, IV/nonce N и предайте aad.
Добавете двубайтов етикет към вече шифрованите данни, ако е имало парола, или към изходните данни, ако парола не е имало.
Първият байт има стойност: той показва, били ли са данните шифровани с парола:
- 0x73 — данните са криптирани с парола;
- 0x13 — данните не са криптирани с парола.
Вторият байт — постоянно значение 0x37.
Отново криптирайте резултата с AES-GCM, използвайки същия iv = N и същия aad. Това дава финалния шифрован текст ct.
Свържете байтовете в низ: blob = N .. S .. ct
Изпрати blob на сървъра заедно с ID. Сървърът връща blob по този ID и не може да бъде заменен: клиентът първо проверява ID с използването на N и K още преди декриптиране, а след това — през aad.
Клиентът съхранява K. K никога не се изпраща на сървъра. Pk също не се изпраща; всичко, свързано с паролата, се изчиства от паметта.
Клиентът генерира линк: origin/#ID/K
Тук ID и K — низове в базов формат base64url.
Когато получателят отвори линка:
- браузърът отхвърля всичко, което започва с #; това се нарича location.hash;
- клиентското приложение се зарежда от сървъра;
- според мен, това е основна дупка: всъщност отново се сблъскваме с това, че „TLS е дупчив“;
- въпреки това, нищо не пречи да съхранявате клиента офлайн;
- в идеалния случай трябва да има отделен самостоятелен клиент.
Клиентският JavaScript проверява location.hash и ако там има ID и K, той зарежда данните от сървъра.
След това проверява, декриптира и, ако е необходимо, иска парола и декриптира отново.
Лиценз
Проектът се разпространява под GPLv3.
Източник: linux.org.ru
