Datový klíč vzniká u vás
Prohlížeč vytvoří náhodný klíč DEK. Tím se šifruje balík vašich odpovědí pomocí XChaCha20-Poly1305.
Soukromí bez mlhy
Jak chráníme vaše soukromí
Joiano je postavené tak, aby se citlivé odpovědi šifrovaly už ve vašem prohlížeči. Server pomáhá s účtem, platbou, synchronizací a průnikem, ale nemá klíč k přečtení vašich odpovědí.
1 Prohlížeč vytvoří datový klíč.
2 Heslo a záchranný klíč jej jen zabalí.
3 Server uloží šifrotext a obálky.
4 Shody se počítají z neprůhledných tokenů.
Obálkové šifrování
Heslo nešifruje přímo odpovědi
Z hesla a záchranného klíče se přes Argon2id odvodí obálkové klíče. Ty umí rozbalit DEK, ne samotný server.
Ověření hesla je oddělené
Server má samostatný verifier pro přihlášení. Je z jiné soli než klíč pro obálku, takže jím nejde odbalit DEK.
Párování
Společný klíč neposíláme v odkazu.
Při pozvání si partneři vymění jen veřejné klíče X25519. Jednorázové tajemství PS je až za znakem # ve fragmentu odkazu, takže ho prohlížeč neposílá serveru. Každý klient si potom dopočítá stejný párový klíč CK z výměny klíčů a PS.
Server CK nezná. Po spárování si každý klient uloží CK jen jako šifrovanou obálku pod vlastním DEK, aby bylo možné shody obnovit po přihlášení.
Tokenový průnik
Klient vybere vhodné položky
Jen u vás se z dešifrovaných odpovědí vytvoří množina položek, které nejsou hranice a mají dostatečný zájem.
Položky se nahrají jako HMAC tokeny
Token je odvozený z CK a item_id. Bez CK vypadá pro server jako náhodná hodnota a nejde přímo namapovat na katalog.
Partner vidí jen společné
Server spočítá průnik tokenů. Klient si ho lokálně přeloží zpět na položky, které mají oba, ne na ne-shody druhého.
Poctivý rozsah
Co server vidí a co nevidí
Server vidí
- Neprůhledný přihlašovací kód, stav session a technická metadata nutná pro provoz.
- Šifrotext odpovědí, nonce, soli, parametry KDF, zabalené klíče a verifier hesla.
- Veřejné párovací klíče, hash jednorázového invite tokenu a stav pozvánky.
- Neprůhledné PSI tokeny, velikosti množin obou partnerů a velikost průniku.
- Platební stav páru oddělený v billing vrstvě přes neprůhledné couple_id.
Server nevidí
- Vaše čitelné odpovědi, hranice ani heslo v podobě použitelné k dešifrování.
- DEK, SEED, obálkové klíče KEK ani párový klíč CK.
- Význam PSI tokenů, tedy které konkrétní položky jste označili.
- Ne-shody partnera. Ty se klientovi nikdy nepřekládají na položky.
- Jméno, e-mail ani telefon, protože je v aplikaci nevyžadujeme.
Limity v1
Silné proti úniku databáze, otevřené o budoucích krocích.
Současný model je navržený hlavně proti úniku databáze, záloh a proti čtení dat insiderem. V1 stále posílá heslo serveru přes TLS kvůli ověření, takže aktivně kompromitovaný běžící server v okamžiku přihlášení je silnější hrozba.
Roadmapa počítá s OPAQUE aPAKE pro přihlášení bez posílání hesla a s oblivious PSI, které skryje i velikosti množin. Tyto kroky jsou vědomé zpevnění, ne skrytý slib dnešní verze.