Vaulted
Audit in 5 minuti

Verifica tu stesso la cifratura zero-knowledge di Vaulted

Non fidarti degli strumenti di sicurezza — verificali. Quattro test nel browser, nessuna installazione, cinque minuti.

La checklist in 60 secondi

Leggi prima questo. La guida dettagliata qui sotto tratta ogni passaggio in profondità.

  1. 1

    Apri DevTools → tab Network

    In Vaulted, premi Cmd+Option+I (macOS) o F12 (Windows/Linux). Passa al tab Network e filtra per Fetch/XHR.

  2. 2

    Crea un segreto e ispeziona il POST

    Digita una stringa canary riconoscibile (es. CANARY-12345) e clicca su Create. Trova la richiesta POST /api/secrets. Apri il tab Payload — vedrai solo testo cifrato (base64) e iv. Cerca nel body la tua canary; non c'è.

  3. 3

    Ispeziona il link di condivisione

    Guarda il link generato. La chiave di cifratura si trova dopo il # (il frammento URL). Secondo RFC 3986, i browser non inviano mai i frammenti al server — né nelle righe di richiesta, né negli header, né nei referrer.

  4. 4

    Conferma che la decifratura avviene lato client

    Apri il link in una nuova scheda. La risposta GET da /api/secrets/[id] restituisce solo testo cifrato. Nel pannello Sources, cerca crypto.subtle.decrypt — quella chiamata viene eseguita nel tuo browser, non sul nostro server.

Apri Vaulted e inizia →Leggi il modello di minaccia

Cosa stai verificando

La promessa di Vaulted è precisa: il server non vede mai il tuo testo in chiaro né la tua chiave di cifratura. Ciò si traduce in quattro proprietà osservabili:

  1. Il testo in chiaro non appare in nessuna richiesta di rete.
  2. La chiave di cifratura non appare in nessuna richiesta di rete.
  3. Il frammento URL (dove risiede la chiave) non raggiunge mai il server.
  4. I dati lato server da soli non possono ricostruire il segreto.

Se tutte e quattro reggono, l'architettura è zero-knowledge per costruzione — nessun linguaggio di marketing necessario.

Test 1 — Il testo in chiaro non attraversa mai la rete

  1. Apri vaulted.fyi.
  2. Apri DevTools e passa al tab Network. Filtra per Fetch/XHR.
  3. Digita una stringa riconoscibile nel campo segreto — qualcosa come CANARY-12345.
  4. Clicca su Create.

Vedrai una singola POST a /api/secrets. Cliccaci e guarda il tab Payload.

Il body contiene un campo ciphertext e un campo iv. Entrambi sono blob codificati in base64url. Cerca nel payload CANARY-12345 — non c'è. Il testo in chiaro è stato cifrato nel browser prima che la richiesta venisse inviata.

Se vuoi essere scrupoloso, imposta la limitazione di rete su «Slow 3G» e ripeti. Il testo cifrato appare ancora come rumore; il testo in chiaro non è ancora da nessuna parte.

Test 2 — La chiave non attraversa mai la rete

Dopo aver creato il segreto, Vaulted ti mostra un link di condivisione. Ha questo aspetto:

https://vaulted.fyi/s/abc123#dGhpcyBpcyBhIGtleQ
                              ^^^^^^^^^^^^^^^^^^^^
                              encryption key (base64url)

La parte dopo # è il frammento URL. Secondo RFC 3986, i browser elaborano i frammenti localmente — non appaiono mai nelle righe di richiesta HTTP, negli header o nei referrer.

Per dimostrarlo:

  1. Copia il link di condivisione.
  2. Aprilo in una nuova scheda con il tab Network dei DevTools aperto.
  3. Trova la richiesta GET /s/abc123.
  4. Guarda il tab Headers — URL completo della richiesta, nessun frammento.
  5. Guarda il tab Request — nessun frammento.
  6. Controlla document.referrer nella pagina successiva — frammento rimosso.

La chiave di cui il destinatario ha bisogno per decifrare il segreto era nell'URL, ma è rimasta nel suo browser. Il server ha visto GET /s/abc123 e nient'altro.

Test 3 — Il server da solo non può decifrare

Apri un terminale e curl il segreto direttamente:

curl https://vaulted.fyi/api/secrets/abc123

Riceverai un JSON contenente ciphertext e iv. Questo è l'intero stato lato server del tuo segreto.

Ora prova a dargli un senso. Senza la chiave dal frammento URL, non puoi. AES-256-GCM con una chiave casuale generata correttamente è, per tutti gli scopi pratici, indistinguibile dal rumore casuale. Un dump completo del database dai server di Vaulted produrrebbe esattamente questo — blob cifrati e metadati.

Questa è la definizione letterale di zero-knowledge: il server memorizza dati che non può leggere.

Test 4 — La cifratura avviene in JavaScript che puoi vedere

Vaulted usa la Web Crypto API, che è una primitiva del browser — non c'è nessun WASM offuscato o modulo nativo che nasconde il lavoro. Puoi osservare la cifratura mentre avviene.

  1. Nei DevTools, apri il tab Sources.
  2. Cerca crypto.subtle.encrypt (usa Cmd+Option+F per la ricerca globale).
  3. Imposta un breakpoint sulla riga che chiama crypto.subtle.encrypt.
  4. Avvia la creazione di un nuovo segreto.
  5. Il breakpoint scatta. Ispeziona gli argomenti: vedrai il tuo testo in chiaro come Uint8Array, la chiave AES-GCM e un IV casuale fresco.
  6. Avanza oltre la chiamata. Il risultato è il testo cifrato che viene inviato.

Stai ora osservando il testo in chiaro diventare testo cifrato, nel tuo browser, prima di qualsiasi richiesta di rete. Non esiste altro percorso che i dati potrebbero prendere.

Cosa dimostra questo

  • Nessun testo in chiaro lascia il browser. Test 1.
  • Nessuna chiave lascia il browser. Test 2.
  • Il server non può decifrare con ciò che memorizza. Test 3.
  • La cifratura è reale e avviene lato client. Test 4.

Questa è l'intera promessa zero-knowledge, dimostrata su un sistema di produzione in esecuzione in cinque minuti.

Cosa non dimostra

La verifica è un lavoro onesto — vale la pena essere chiari sui suoi limiti.

  • I test dimostrano il comportamento in questo momento. Una modifica futura al codice potrebbe violare questa proprietà. Se hai bisogno di garanzie continuative, iscriviti al changelog e riesegui i test periodicamente.
  • Non proteggono dal tuo dispositivo. Un keylogger o un'estensione browser malevola può leggere il testo in chiaro dopo la decifratura. Questo è al di fuori del controllo di qualsiasi web app.
  • Presuppongono che il JavaScript eseguito sia il JavaScript servito da Vaulted. Un attaccante mirato che ha compromesso la CDN potrebbe servire un bundle diverso a un singolo utente. Subresource Integrity e build riproducibili mitigano questo; vedi il nostro modello di minaccia per tutti i dettagli.

Approfondire

Se vuoi scavare più a fondo:

L'argomento più forte per uno strumento di sicurezza non è il suo marketing. È che puoi smontarlo e confermare che fa ciò che dice. Vaulted è costruito in modo che tu possa farlo.

Domande frequenti

Hai domande o hai trovato qualcosa di strano? Scrivi a [email protected] — pubblichiamo la nostra policy di divulgazione responsabile e rispondiamo entro 48 ore.
Condividi un segreto →