1. Definizione
Encryptio è zero-knowledge a riposo: Postgres conserva solo ciphertext del vault, delle note e dei backup di chiave. La master key non è mai scritta nel database.
Non è cifratura end-to-end solo sul client per gli elementi del vault. Al login la master key viene derivata dalla password e tenuta lato server per la durata della sessione, così l'app web e l'API dell'estensione possono decifrare i dati.
In una sessione autenticata il server può leggere il plaintext del vault. Senza password, recovery key o sessione attiva, una copia del database da sola non basta a decifrare il vault.
2. Modello di minaccia
La domanda utile non è «Encryptio può mai decifrare?», ma «in quale stato il server ha la master key?».
| Stato | Il server può leggere il plaintext del vault? |
|---|---|
| Nessun login; ciphertext in Postgres | No: la master key non è nel database |
| Utente collegato (web o estensione) | Sì: master key derivata al login e tenuta per la sessione |
| Reset password senza recovery key | No: la nuova master key non apre il ciphertext precedente |
| Digital Legacy con grant per inattività | Sì, in modo delegato, solo se il proprietario ha attivato l'escrow |
3. Dove avviene la cifratura
Il punto di cifratura dipende dal tipo di dato. I file condivisi sono cifrati nel browser prima dell'upload. Gli elementi del vault no: vengono cifrati dall'applicazione al momento della scrittura nel database.
| Dato | Dove si cifra | Cosa resta sul server |
|---|---|---|
| Password e note del vault | Server applicativo, in scrittura su database | Solo ciphertext AES-GCM |
| File condivisi | Browser, prima dell'upload | Solo blob cifrato su disco |
| Condivisione interna tra utenti Encryptio | Server: chiave AES per-share avvolta con RSA del destinatario | Ciphertext e wrapped key |
| Condivisione esterna (link) | Server, con chiave derivata dal token del link | Ciphertext e hash del token |
| Cache locale dell'estensione | Service worker dell'estensione | Nessuna: resta sul dispositivo |
L'API autenticata dell'estensione restituisce gli elementi del vault già decifrati. È un canale segreto tra sessione (o token Bearer) e client, non un dump di ciphertext.
4. Generazione delle chiavi
Password di login e master key
Alla registrazione ogni account riceve un salt per-utente da 16 byte. La password ha due usi distinti:
- Verifica di login: hash Argon2id (con pepper applicativo) salvato come password_hash.
- Derivazione della master key: PBKDF2-HMAC-SHA256, 600.000 iterazioni, output da 256 bit, da password + pepper + salt. Questa chiave non viene persistita in Postgres.
Dopo un login riuscito la master key resta in Redis, indicizzata per utente e sessione, con TTL (predefinito 12 ore). Non viene mai scritta nel cookie di sessione Flask. Il logout cancella la chiave Redis. In un singolo request viene tenuta solo nel contesto Flask g.
Recovery key
Alla registrazione, e di nuovo a ogni cambio password autenticato, il server genera 32 byte casuali (256 bit). La recovery key è mostrata una sola volta in Base64. Con essa si cifra una copia di backup della master key. La recovery key in chiaro non è memorizzata.
Altre chiavi
- Email: chiave AES derivata in modo deterministico da identificativo utente e segreto di sistema, così login e reset restano possibili senza la master key.
- Condivisione interna: coppia RSA-2048 per utente; la chiave privata è cifrata con la master key del destinatario.
- Condivisione esterna: chiave AES derivata dal token del link (il token in chiaro non è in database).
- File share: chiave AES derivata nel browser dalla password di condivisione scelta dall'utente.
5. Algoritmi oltre AES-256
AES-256-GCM è l'AEAD del vault, delle note, dei segreti TOTP, del backup della master key e dei payload di sharing. Intorno a esso usiamo primitive distinte per autenticazione, derivazione chiavi, wrapping e lookup.
| Uso | Algoritmo | Parametri |
|---|---|---|
| Hash password di login | Argon2id | time cost 3, memory 64 MiB, parallelism 4 |
| Master key | PBKDF2-HMAC-SHA256 | 600.000 iterazioni, 32 byte, salt per-utente e pepper |
| Vault, note, blob, backup chiave | AES-256-GCM | nonce da 96 bit anteposto al ciphertext |
| Ricerca email | HMAC-SHA256 | indirizzo normalizzato; ciphertext email separato |
| Token API, legacy, share esterni | SHA-256 | in database solo l'hash, con pepper |
| Condivisione interna | RSA-2048-OAEP | SHA-256; avvolge una chiave AES per-share |
| File share (browser) | PBKDF2-HMAC-SHA256 + AES-256-GCM | 100.000 iterazioni nel client, poi upload del ciphertext |
| Autenticazione a due fattori | TOTP | segreto cifrato a riposo con la master key |
| Marca temporale blockchain | SHA-256 | solo l'impronta del file in chiaro, calcolata nel browser |
6. Recupero account
Il reset della password di login e il recupero del vault sono operazioni distinte. Un link via email prova che controlli l'indirizzo, non che possiedi la master key.
Reset con recovery key
- L'utente conferma il link di reset e fornisce la recovery key.
- Il server decifra il backup della master key con quella recovery key.
- Con la master key precedente decifra vault, note e segreto TOTP.
- Dalla nuova password deriva una nuova master key e re-cifra tutto.
- Il backup viene re-avvolto con la stessa recovery key. L'email non viene re-cifrata: usa una chiave indipendente dalla password.
Reset senza recovery key
Puoi impostare una nuova password e accedere all'account, ma la nuova master key non apre il ciphertext esistente. I dati del vault restano illeggibili finché non usi la recovery key originale per recuperarli, oppure restano persi.
Cambio password da sessione autenticata
Se conosci ancora la password corrente, il server deriva la master key, re-cifra i dati con la nuova master key e emette una nuova recovery key da salvare al posto della precedente.
Altri meccanismi, non equivalenti
- I codici di recupero 2FA sbloccano solo il secondo fattore, non il vault.
- Digital Legacy può consegnare l'accesso in sola lettura a un contatto email dopo un periodo di attesa. L'escrow della master key per inattività è esplicito e opt-in.
Perdere sia la password sia la recovery key significa perdita permanente dei dati del vault. È il comportamento intenzionale del modello: senza una di quelle due prove, nessuno — incluso Encryptio — può ricostruire la master key dal solo database.
7. Funzioni correlate
- Condivisioni esterne: sempre con scadenza, revocabili dal mittente; l'email contiene solo il link, non il contenuto.
- Estensione Manifest V3: la crittografia locale e le chiamate API passano dal service worker, non dagli script di contenuto.
- Marca temporale Chia: prova di esistenza dell'hash, non marca eIDAS né atto notarile.
8. Cosa questo modello non è
Non affermiamo che «nemmeno Encryptio può mai decifrare». Quella frase descriverebbe un vault cifrato solo nel browser, con chiave che non lascia mai il dispositivo. Encryptio cifra il vault a riposo e decifra in sessione per offrire web app, API e recupero account.
Il valore di sicurezza è questo: un attaccante con solo il database (o un backup a freddo) non ottiene le password del vault. Un attaccante che compromette un processo applicativo durante una sessione attiva è nello stesso perimetro della master key di quella sessione: per questo la chiave sta in Redis con TTL, non nel cookie, e il logout la cancella.
La pagina Sicurezza resta il riassunto per tutti. Questo whitepaper è la descrizione tecnica del modello.
Vuoi usare Encryptio con questo modello di chiavi?