Sicurezza

Modello di crittografia

Formato .rkvey v5: preambolo, AEAD per compartimento, commit append-only e isolamento dei segreti.

Il formato .rkvey v5 (Rust Key Vault) implementa un modello di crittografia multistrato secondo le best practice HKDF e AEAD. Il modello mentale: password principale → chiave principale → sottochiavi → compartimenti crittografati.

Ogni voce è divisa in compartimenti (metadati, segreti protetti, manifest e file allegati), ciascuno con la propria chiave HKDF. Decifrare un compartimento non rivela gli altri.

Modello di crittografia QubKey v5

Parola d'ordine principale

Input dell'utente (UTF-8): mai archiviato in testo normale

KDF

Argon2id

Sale

16 byte (preambolo)

Memoria

64 MB

Iterazioni

3

Parallelismo

4

Produzione

256 bit

Chiave maestra

256 bit · chiave root del vault

HKDF-SHA256

informazioni="hdr"

Chiave dell'intestazione

chiave_intestazione

HKDF-SHA256

informazioni="idx"

Chiave indice

chiave_indice

HKDF-SHA256

info="compartimento"

Chiave dello scomparto

compartimento_chiave

Per voce (v5)

HKDF(master_key, salt=file∥entry_id, info=kind∥sub_id) → Chiave compartimento

Metadati
Segreti
Avv. manifesto
AES-256-GCM

Scomparti crittografati

Derivazione delle chiavi

La derivazione trasforma la password principale in chiavi crittografiche utilizzabili. Argon2id è intenzionalmente intensivo in tempo e memoria (~500 ms, 64 MB) per imporre limiti di velocità offline. In v5, ogni compartimento di voce riceve poi la propria chiave via HKDF.

Input utente → password principale (UTF-8)

Argon2idmaster_key (256 bit) con salt casuale

HKDF-SHA256index_key per il B-Tree

HKDF-SHA256compartment_key per voce e tipo di compartimento (metadati, segreti, allegato…)

ParametroValoreDescrizionePredefinito
VariantArgon2idVariante ibrida raccomandata da OWASP — resistente a GPU e attacchi side-channel
Memory64 MBMemoria per derivazione — aumenta il costo hardware di attacchi paralleli65536 KB
Iterations3Passate sulla memoria — equilibrio sicurezza/prestazioni (~500 ms)
Parallelism4Thread paralleli
Output32 bytesLunghezza della chiave derivata
Salt16 bytesSalt casuale nel preambolo

Crittografia AEAD

AES-256-GCM (predefinito)

  • Supporto hardware AES-NI su processori moderni
  • Nonce: 12 byte, tag di autenticazione: 16 byte
  • Limite teorico: ~64 GB di dati crittografati per chiave

Quando sceglierlo: macchine con accelerazione hardware AES, uso quotidiano.

Cifrario predefinito sulla maggior parte delle piattaforme per prestazioni ottimali.

XChaCha20-Poly1305 (opzionale)

  • Nonce esteso: 24 byte (probabilità di collisione trascurabile)
  • Nessuna dipendenza hardware — prestazioni costanti su tutte le CPU
  • Consigliato per chiavi di lunga durata

Quando sceglierlo: vault archiviati, macchine senza AES-NI, preferenza per ChaCha20.

Attivabile nelle impostazioni avanzate del vault.

Struttura del file

preamble
header.enc
btree_root.enc
btree_nodes.enc
core_meta.enc
protected_secrets.enc
attachment_manifest.enc
attachment_blob_*.enc
commit_N
footer (validated)

Descrizione della struttura (v5):

  • preamble — magic bytes, versione del formato, salt Argon2id
  • header.enc — metadati crittografati del vault (nome, data di creazione, impostazioni)
  • index/ — B-Tree crittografato per ricerca O(log n) senza decifrare i segreti
  • compartments/ — blocchi AEAD per tipo: metadati, segreti protetti, manifest, allegati
  • append/ — regione commit: nuovi compartimenti + snapshot indice + footer validato

Integrità e commit

Resilienza

I commit append-only garantiscono l'integrità in caso di interruzione:

  1. I nuovi compartimenti vengono aggiunti in coda al file
  2. Viene scritto uno snapshot crittografato dell'indice
  3. I dati vengono sincronizzati sul disco (fsync)
  4. Un footer validato chiude il commit (punto di consistenza)

Scenario reale: modifichi una voce e salta la corrente durante la scrittura. Al riavvio, QubKey trova il footer valido più recente — nessuna perdita di dati, nessuna corruzione silenziosa. La compattazione periodica riscrive un file pulito quando c'è troppo spazio obsoleto.

Isolamento per compartimento

Tramite HKDF-SHA256, ogni compartimento ottiene il proprio compartment_key, derivato dalla chiave principale con ID voce e tipo di compartimento. Conseguenze pratiche:

  • Visualizzare una voce decifra solo i metadati; i segreti restano mascherati fino alla rivelazione esplicita
  • Gli allegati vengono caricati singolarmente (download / anteprima), non all'apertura del vault
  • L'indice B-Tree utilizza il proprio index_key, separato dai dati
  • Modificare un segreto non riscrive necessariamente i file allegati invariati

Questo isolamento è implementato nativamente nel formato .rkvey v5.

Primitive crittografiche

PrimitivaUsoLibreria
Argon2idPassword → derivazione chiaveargon2 (RustCrypto)
HKDF-SHA256Chiave → derivazione sottochiavihkdf (RustCrypto)
AES-256-GCMCrittografia AEADaes-gcm (RustCrypto)
XChaCha20-Poly1305Crittografia AEAD (alternativa)chacha20poly1305 (RustCrypto)
HMAC-SHA256Integrità del filehmac (RustCrypto)
CSPRNGGenerazione casualegetrandom (SO)