Ad Nihilum 0.4.3 er blevet lanceret — en minimalistisk tjeneste til udveksling af krypterede beskeder baseret på princippet om «læst — brændt», der primært er rettet mod self-hosting.
Serveren fungerer kun som en blind opbevaringsenhed. Kryptering og dekryptering sker udelukkende på klientsiden, i browseren (via AES-GCM).
Funktioner
- lokal kryptering og dekryptering, server ser aldrig nøglen;
- understøttelse af et ekstra lag kryptering med en adgangskode, som (1) serveren ikke kan få kendskab til, (2) ikke kan udledes af den overførte link;
- projektet indeholder omkring 2200 linjer serverkode i C og 600 linjer klientkode i JS, hvilket forenkler revision;
- Ad Nihilum afhænger kun af libmicrohttpd. En modificeret version af QRCode.js leveres til generation af QR-koder;
- der medfølger en instruktion til hurtig opsætning af lokal tjeneste uden ekstern IP;
- Ad Nihilum fungerer også på Android, og der er vedhæftet et passende skript til bygning i Termux;
- enkelttrådet og synkron server.
Ændringer
Omfattende redesign
- Siderne til sendelse og modtagelse af beskeder er adskilt, med den tilsvarende klientkode.
- Generelt er designet blevet stærkt ændret og justeret i henhold til ønsker fra lorerne.
- «Enkel» og lokal klient:
- klientsiderne kan gemmes lokalt og bruges fra file://.
Browserpolitikker
- CSP er blevet implementeret for at bekæmpe XSS;
- serveren sender HSTS.
Andre ændringer
- projektet er blevet omdøbt fra Epha-ots;
- domænet adnihilum.net er blevet købt;
- TLS sikres ved hjælp af Let’s Encrypt, det er værd at bemærke (der er ikke penge);
- arbejdet med filer er forenklet;
- overgang til fat-pegere;
- små fejl er blevet rettet;
- auto-jsminify og bygning af klientfiler ved bygning via CMake.
Oversigt over protokollen
Generer tre tilfældige værdier: nøgle K, initialiseringsvektor N og salt Angreb op til 1,2. K — 256 bit, N — 96 bit, Angreb op til 1,2 — 128 bit.
Udskriv ID af K og Angreb op til 1,2 ved hjælp af HKDF baseret på SHA-256.
Dann en streng af yderligere autentificerede data aad — det er blot en streng af typen: id=ID
Hvis brugeren har angivet en adgangskode:
- udskriv Pk fra adgangskoden og Angreb op til 1,2 ved hjælp af PBKDF2, SHA-256, 800000 iterationer;
- den samme salt bruges til alt;
- krypter data ved hjælp af AES-GCM, bruge nøgle Pk, IV/nonce N og overfør aad.
Tilføj en to-byt tag til allerede krypterede data, hvis der var en adgangskode, eller til de originale data, hvis der ikke var nogen adgangskode.
Den første byte har værdien: den viser, om dataene blev krypteret med en adgangskode:
- 0x73 — data er krypteret med en adgangskode;
- 0x13 — data er ikke krypteret med en adgangskode.
Andet byte — konstant værdi 0x37.
Krypter resultatet igen med AES-GCM, og brug den samme iv = N og den samme aad. Dette giver den endelige krypterede tekst ct.
Sammenkæd bytes i en streng: blob = N .. S .. ct
Send blob til serveren sammen med ID. Serveren returnerer blob på dette ID og kan ikke ændre det: klienten vil først verificere ID ved hjælp af N og K allerede før dekrypteringen og derefter — gennem aad.
Klienten opbevarer K. K sendes aldrig til serveren. Pk sendes heller ikke; alt relateret til adgangskoden slettes fra hukommelsen.
Klienten danner et link: origin/#ID/K
Her ID og K — strenge i base64url format.
Når modtageren åbner linket:
- browseren ignorerer alt, der starter med #; dette kaldes location.hash;
- klientapplikationen indlæses fra serveren;
- efter min mening er dette det største sikkerhedsproblem: vi står faktisk igen overfor, at "TLS er sårbart";
- men intet forhindrer opbevaring af klient offline;
- ideelt set bør der være en separat standalone-klient.
Klientens JavaScript tjekker location.hash, og hvis der er ID og K, indlæser det data fra serveren.
Derefter tjekker det dem, dekrypterer og, hvis nødvendigt, anmoder om adgangskoden og dekrypterer igen.
Licens
Projektet distribueres under GPLv3.
Kilde: linux.org.ru
