IN ARRIVO

LA SICUREZZA NON È UNA FUNZIONE. È LA BASE.

Architettura di sicurezzaDentro VORQYN.

Dalla password principale e dalla gerarchia delle chiavi ai commit autenticati, al ripristino dopo un arresto e alla sincronizzazione end-to-end.

Argon2idHKDF-SHA-256XChaCha20-Poly1305Rust CoreAuthenticated Commits
Indice ⌄
Diagrammi interattiviRiferimento tecnico

01 / VISUAL SECURITY LAB

Esplora l’architettura

Esplora derivazione delle chiavi, record cifrati, scritture, sincronizzazione e limiti di sicurezza attraverso diagrammi interattivi.

01

INTERACTIVE · SECURITY ENGINEERING

Architettura di sicurezza

Flutter gestisce l’interfaccia; il core Rust verifica crittografia, formati e stati. Adapter di piattaforma e provider di archiviazione sono separati.
Spiegazione semplice

Flutter gestisce l’interfaccia; il core Rust verifica crittografia, formati e stati. Adapter di piattaforma e provider di archiviazione sono separati.

Limite di sicurezza

Un client compromesso può esporre il testo in chiaro durante l’uso.

Dettagli tecnici

Flutter gestisce l’interfaccia; il core Rust verifica crittografia, formati e stati. Adapter di piattaforma e provider di archiviazione sono separati.

Un client compromesso può esporre il testo in chiaro durante l’uso.

Leggi il capitolo ↗
02

INTERACTIVE · SECURITY ENGINEERING

Password + Secret Factor

Password principale
Argon2id v1.3
Secret Factor (256 bit)
CSPRNG → 32 bytes
↓
HKDF-SHA-256
Unlock key → envelope → LPRK
Viene rubato solo il vault cifrato. Il Secret Factor manca; la password non basta.
Spiegazione semplice

Il Secret Factor contiene 256 bit casuali ed è indipendente dalla password. Protegge alcuni scenari di furto del vault, ma malware con gli stessi privilegi potrebbe ottenere anche il file del fattore.

Limite di sicurezza

Un Factor locale non equivale automaticamente a MFA indipendente.

Dettagli tecnici

Il Secret Factor contiene 256 bit casuali ed è indipendente dalla password. Protegge alcuni scenari di furto del vault, ma malware con gli stessi privilegi potrebbe ottenere anche il file del fattore.

Un Factor locale non equivale automaticamente a MFA indipendente.

Leggi il capitolo ↗
03

INTERACTIVE · SECURITY ENGINEERING

Gerarchia delle chiavi

Password principale + Secret Factor (256 bit)
Unlock key → envelope → LPRK
LPRK
Vault Epoch Key
DEK del record
Collection Keys
La chiave di sblocco apre una busta che protegge il Local Profile Root Key (LPRK) generato indipendentemente. Vault Epoch, DEK per revisione e Collection Keys separano gli ambiti.
Spiegazione semplice

La chiave di sblocco apre una busta che protegge il Local Profile Root Key (LPRK) generato indipendentemente. Vault Epoch, DEK per revisione e Collection Keys separano gli ambiti.

Limite di sicurezza

Senza un percorso di recupero, la perdita delle chiavi può essere irreversibile.

Dettagli tecnici

La chiave di sblocco apre una busta che protegge il Local Profile Root Key (LPRK) generato indipendentemente. Vault Epoch, DEK per revisione e Collection Keys separano gli ambiti.

Senza un percorso di recupero, la perdita delle chiavi può essere irreversibile.

Leggi il capitolo ↗
04

INTERACTIVE · SECURITY ENGINEERING

Cifratura per record

Login ADEK A1Revision 1
Login BDEK B1Revision 1
Login CDEK C1Revision 1
Login DDEK D1Revision 1
Gli altri record restano invariati
Spiegazione semplice

Ogni modifica genera una revisione immutabile con un nuovo DEK casuale a 256 bit. I dati pubblicati in precedenza non vengono sovrascritti.

Limite di sicurezza

Revisioni precedenti possono restare disponibili secondo la retention.

Dettagli tecnici

Ogni modifica genera una revisione immutabile con un nuovo DEK casuale a 256 bit. I dati pubblicati in precedenza non vengono sovrascritti.

Revisioni precedenti possono restare disponibili secondo la retention.

Leggi il capitolo ↗
05

INTERACTIVE · SECURITY ENGINEERING

Scritture atomiche e ripristino

VALIDATEDEKENCRYPTWRITE TEMPFLUSHPUBLISH RECORDPUBLISH COMMITUPDATE HEAD
Il commit precedente resta valido. L’oggetto temporaneo incompleto non è un nuovo stato.
Spiegazione semplice

La scrittura valida, genera revisione e DEK, cifra, salva temporaneamente, esegue flush, pubblica oggetti e commit e infine aggiorna l’head.

Limite di sicurezza

Oggetti mancanti o guasti hardware possono impedire il ripristino.

Dettagli tecnici

La scrittura valida, genera revisione e DEK, cifra, salva temporaneamente, esegue flush, pubblica oggetti e commit e infine aggiorna l’head.

Oggetti mancanti o guasti hardware possono impedire il ripristino.

Leggi il capitolo ↗
06

INTERACTIVE · SECURITY ENGINEERING

Monolite vs. object store

Monolite ingenuo (schema)
100 GB VAULT
Δ RECORD
Object store
BLOBRECRECBLOBRECRECBLOBRECRECBLOBRECREC
Δ RECORD + INDEX + COMMIT
Modificare una password in un vault da 100 GB non richiede automaticamente di riscrivere tutto. Il traffico effettivo dipende da indici e trasporto.
Spiegazione semplice

Modificare una password in un vault da 100 GB non richiede automaticamente di riscrivere tutto. Il traffico effettivo dipende da indici e trasporto.

Limite di sicurezza

Anche altri sistemi possono usare una sincronizzazione delta efficiente.

Dettagli tecnici

Modificare una password in un vault da 100 GB non richiede automaticamente di riscrivere tutto. Il traffico effettivo dipende da indici e trasporto.

Anche altri sistemi possono usare una sincronizzazione delta efficiente.

Leggi il capitolo ↗
07

INTERACTIVE · SECURITY ENGINEERING

Grafo dei commit autenticato

Commit A
Commit B
Commit C · Device 1
Commit D · Device 2
Merge E
Un provider malevolo può nascondere commit autenticati.
Spiegazione semplice

I commit autenticati collegano oggetti attivi e antenati. Writer diversi possono generare rami validi; l’orologio da solo non identifica il vincitore.

Limite di sicurezza

Un provider malevolo può nascondere commit autenticati.

Dettagli tecnici

I commit autenticati collegano oggetti attivi e antenati. Writer diversi possono generare rami validi; l’orologio da solo non identifica il vincitore.

Un provider malevolo può nascondere commit autenticati.

Leggi il capitolo ↗
08

INTERACTIVE · SECURITY ENGINEERING

Sincronizzazione end-to-end

Dispositivo A
⇆AEAD · CIPHERTEXT
Provider
⇆AEAD · CIPHERTEXT
Dispositivo B
Modifiche locali offline con upload successivo.
Spiegazione semplice

I client cifrano in locale e scambiano oggetti cifrati. Gli oggetti dati precedono il commit che li riferisce; modifiche offline possono creare rami.

Limite di sicurezza

Il provider può cancellare, ritardare o riproporre oggetti cifrati.

Dettagli tecnici

I client cifrano in locale e scambiano oggetti cifrati. Gli oggetti dati precedono il commit che li riferisce; modifiche offline possono creare rami.

Il provider può cancellare, ritardare o riproporre oggetti cifrati.

Leggi il capitolo ↗
09

INTERACTIVE · SECURITY ENGINEERING

Integrità ≠ freschezza

Commit C1Autentico ma datatoAEAD ✓
←
Commit C2Commit recente confermatoAEAD ✓
AEAD autentica uno stato vecchio, ma non la freschezza.
Spiegazione semplice

AEAD autentica i contenuti, non la freschezza. Per rilevare rollback completi serve un riferimento indipendente e affidabile a uno stato recente.

Limite di sicurezza

Un rollback completo richiede un ancoraggio indipendente affidabile.

Dettagli tecnici

AEAD autentica i contenuti, non la freschezza. Per rilevare rollback completi serve un riferimento indipendente e affidabile a uno stato recente.

Un rollback completo richiede un ancoraggio indipendente affidabile.

Leggi il capitolo ↗
10

INTERACTIVE · SECURITY ENGINEERING

Permessi Business & Enterprise

ROLE
PRIVATE
FINANCE
DEVELOPMENT
Owner
✓
✓
✓
Finance User
—
✓
—
Developer
—
—
✓
Le chiavi delle Collection, non solo i ruoli server, limitano l’accesso
Spiegazione semplice

I ruoli Owner, Admin, Editor e Viewer non sostituiscono le autorizzazioni sulle chiavi. Le Collection hanno chiavi separate; informazioni già conosciute non possono essere revocate.

Limite di sicurezza

I testi in chiaro già conosciuti non possono essere revocati retroattivamente.

Dettagli tecnici

I ruoli Owner, Admin, Editor e Viewer non sostituiscono le autorizzazioni sulle chiavi. Le Collection hanno chiavi separate; informazioni già conosciute non possono essere revocate.

I testi in chiaro già conosciuti non possono essere revocati retroattivamente.

Leggi il capitolo ↗
11

INTERACTIVE · SECURITY ENGINEERING

Modello delle minacce

Seleziona scenario

Vault cifrato rubato

Dettagli tecnici

Argon2id, AEAD e Factor separato

Limite di sicurezza

Custodia del Factor e qualità password

Spiegazione semplice

Il modello considera furto, manomissione, crash, disco pieno, provider malevolo, rollback e dispositivo compromesso. Ogni meccanismo ha un limite.

Limite di sicurezza

Nessuna difesa da sola copre ogni scenario.

Dettagli tecnici

Il modello considera furto, manomissione, crash, disco pieno, provider malevolo, rollback e dispositivo compromesso. Ogni meccanismo ha un limite.

Nessuna difesa da sola copre ogni scenario.

Leggi il capitolo ↗
12

INTERACTIVE · SECURITY ENGINEERING

Audit e prove

01   Architecture02   Implementation03   Automated tests04   Platform validation05   Independent audit
L’architettura definisce invarianti verificabili e confini di fiducia espliciti.
Spiegazione semplice

Un audit richiede contratti verificabili per KDF, nonce, AAD, formati, commit, errori, persistenza, firme e build distribuite.

Limite di sicurezza

La verifica collega protocolli, implementazione, test e validazione sulle piattaforme.

Dettagli tecnici

Un audit richiede contratti verificabili per KDF, nonce, AAD, formati, commit, errori, persistenza, firme e build distribuite.

La verifica collega protocolli, implementazione, test e validazione sulle piattaforme.

Leggi il capitolo ↗

02 / TECHNICAL REFERENCE · V1.2

Riferimento tecnico

Il riferimento tecnico descrive meccanismi crittografici, formati, minacce, errori e scelte architetturali. Questa edizione propone sintesi tecniche e collegamenti al riferimento tedesco completo.

01La sicurezza è la base+

La sicurezza copre l’intero ciclo di vita: creazione, utilizzo, modifica, sincronizzazione, ripristino ed eliminazione. Anche i guasti sono parte del modello.

Specifica completa (tedesco) ↗

02Sei principi di sicurezza+

Riservatezza, integrità, consistenza, recuperabilità, disponibilità e sovranità sono obiettivi distinti. Un vault autentico potrebbe essere obsoleto.

Specifica completa (tedesco) ↗

03Architettura del sistema+

Flutter gestisce l’interfaccia; il core Rust verifica crittografia, formati e stati. Adapter di piattaforma e provider di archiviazione sono separati.

Specifica completa (tedesco) ↗

04Primitive crittografiche+

Argon2id v1.3 (128 MiB, 3 iterazioni, 4 corsie, output 256 bit), HKDF-SHA-256 e XChaCha20-Poly1305 (chiave 256 bit, nonce 192 bit e tag 128 bit) hanno ruoli distinti.

Argon2id v1.3 · 128 MiB / 3 / 4 · HKDF-SHA-256 · XChaCha20-Poly1305

Specifica completa (tedesco) ↗

05Password principale e Secret Factor+

Il Secret Factor contiene 256 bit casuali ed è indipendente dalla password. Protegge alcuni scenari di furto del vault, ma malware con gli stessi privilegi potrebbe ottenere anche il file del fattore.

VQYFACT1 · 32-byte CSPRNG secret · HKDF-SHA-256

Specifica completa (tedesco) ↗

06Gerarchia delle chiavi+

La chiave di sblocco apre una busta che protegge il Local Profile Root Key (LPRK) generato indipendentemente. Vault Epoch, DEK per revisione e Collection Keys separano gli ambiti.

Unlock → Envelope → LPRK → VEK → DEK

Specifica completa (tedesco) ↗

07Dati associati autenticati+

I dati associati autenticati (AAD) legano il testo cifrato al vault, all’oggetto, alla revisione e alla versione. Impediscono sostituzioni indebite; AAD non è necessariamente segreto.

AAD: vault_id | object_id | revision_id | epoch | version

Specifica completa (tedesco) ↗

08Un vault logico, molti oggetti cifrati+

Il vault logico comprende record cifrati, blob, commit e puntatori head. Un head è un riferimento ricostruibile, non l’unica autorità crittografica.

meta/ · commits/ · records/ · blobs/ · heads/

Specifica completa (tedesco) ↗

09Record immutabili e revisioni+

Ogni modifica genera una revisione immutabile con un nuovo DEK casuale a 256 bit. I dati pubblicati in precedenza non vengono sovrascritti.

Specifica completa (tedesco) ↗

10Grafo dei commit autenticato+

I commit autenticati collegano oggetti attivi e antenati. Writer diversi possono generare rami validi; l’orologio da solo non identifica il vincitore.

commit ID · vault ID · parent IDs · record refs

Specifica completa (tedesco) ↗

11Transazione di scrittura completa+

La scrittura valida, genera revisione e DEK, cifra, salva temporaneamente, esegue flush, pubblica oggetti e commit e infine aggiorna l’head.

VALIDATE → ENCRYPT → WRITE → FLUSH → PUBLISH RECORD → PUBLISH COMMIT → HEAD

Specifica completa (tedesco) ↗

12Blackout, arresti e ripristino+

Dopo un crash si verificano l’autenticità dei commit e la completezza degli oggetti. Un unico tip valido può essere ricostruito; i casi ambigui richiedono gestione esplicita.

Specifica completa (tedesco) ↗

13Disco pieno+

Lo spazio può esaurirsi durante la scrittura. Ogni write e flush va controllato; un commit non deve confermare oggetti incompleti.

Specifica completa (tedesco) ↗

14Sicurezza del file system+

NTFS, Linux, macOS e piattaforme mobili hanno garanzie differenti. Symlink, junction, corse TOCTOU e guasti hardware sono rischi reali.

Specifica completa (tedesco) ↗

15Allegati e chunk cifrati+

Gli allegati grandi vengono divisi in chunk cifrati, ad esempio fino a 4 MiB di payload. Ordine e contesto sono autenticati; gli hash riguardano il ciphertext.

4 MiB chunk profile · SHA-256(ciphertext)

Specifica completa (tedesco) ↗

16Il vault da 100 GB+

Modificare una password in un vault da 100 GB non richiede automaticamente di riscrivere tutto. Il traffico effettivo dipende da indici e trasporto.

Specifica completa (tedesco) ↗

17Manifest, indici e scalabilità+

Manifest autenticati e indici gerarchici distribuiscono i riferimenti. La catena di integrità deve collegare radice e oggetti finali.

Specifica completa (tedesco) ↗

18Sincronizzazione cifrata end-to-end+

I client cifrano in locale e scambiano oggetti cifrati. Gli oggetti dati precedono il commit che li riferisce; modifiche offline possono creare rami.

Specifica completa (tedesco) ↗

19SFTP, WebDAV e object storage+

SFTP, WebDAV/HTTPS e storage S3-like offrono capacità diverse per write condizionali, rinomina e completezza dei listing. Ogni adapter deve rispettarle.

SFTP · WebDAV/HTTPS · S3-like

Specifica completa (tedesco) ↗

20Conflitti tra dispositivi+

Due dispositivi possono modificare lo stesso record da un antenato comune. I rami sono mantenuti e uniti in modo controllato, non selezionati solo per timestamp.

Specifica completa (tedesco) ↗

21Protezione dai rollback+

AEAD autentica i contenuti, non la freschezza. Per rilevare rollback completi serve un riferimento indipendente e affidabile a uno stato recente.

Specifica completa (tedesco) ↗

22Permessi Business ed Enterprise+

I ruoli Owner, Admin, Editor e Viewer non sostituiscono le autorizzazioni sulle chiavi. Le Collection hanno chiavi separate; informazioni già conosciute non possono essere revocate.

Owner · Admin · Editor · Viewer

Specifica completa (tedesco) ↗

23Rotazione delle chiavi+

Cambiare password principale può richiedere solo una nuova busta di chiavi. Una chiave dati compromessa può richiedere vera nuova cifratura.

Specifica completa (tedesco) ↗

24Backup e disaster recovery+

Il backup recuperabile include metadati, buste, commit, record, chunk e segreti necessari al restore. La completezza e l’autenticità vanno verificate.

Specifica completa (tedesco) ↗

25Eliminazione e tombstone+

I tombstone autenticati rappresentano le cancellazioni. Revisioni precedenti possono sopravvivere in backup; non si garantisce la cancellazione fisica universale.

Specifica completa (tedesco) ↗

26Chiavi private e nuova autenticazione+

L’esportazione di chiavi SSH private richiede una nuova autorizzazione nel core Rust, non un semplice dialogo. In caso di errore l’export resta bloccato.

Specifica completa (tedesco) ↗

27Protezione durante l’esecuzione+

Il blocco della sessione e la zeroization riducono la vita dei segreti controllati, ma copie possono restare in Dart, clipboard, swap o crash dump.

Specifica completa (tedesco) ↗

28Privacy e zero knowledge+

Il provider non possiede le chiavi di decrittazione, ma dimensioni, orari, quantità di oggetti, IP e metadati di rete possono rimanere visibili.

Specifica completa (tedesco) ↗

29Supply chain del software+

Dipendenze dirette e transitive, feature attive, advisory, configurazioni e binari effettivamente distribuiti rientrano nella valutazione.

Specifica completa (tedesco) ↗

30Modello delle minacce+

Il modello considera furto, manomissione, crash, disco pieno, provider malevolo, rollback e dispositivo compromesso. Ogni meccanismo ha un limite.

Specifica completa (tedesco) ↗

31Audit e verificabilità+

Un audit richiede contratti verificabili per KDF, nonce, AAD, formati, commit, errori, persistenza, firme e build distribuite.

Architecture → Implementation → Tests → Platform → Independent review

Specifica completa (tedesco) ↗

32Limiti espliciti+

Nessuna promessa di sicurezza totale su endpoint compromessi, ripristino senza chiavi, cancellazione universale o rilevamento rollback senza ancoraggio indipendente.

Specifica completa (tedesco) ↗

33Domande frequenti+

Le FAQ distinguono furto del vault, Secret Factor, uso offline, limiti del cloud e differenza tra autenticità e freschezza.

Specifica completa (tedesco) ↗

34Sicurezza attraverso l’architettura+

Argon2id, Secret Factor, HKDF, AEAD, DEK individuali, AAD, record immutabili e commit autenticati formano un modello di difesa a strati.

Specifica completa (tedesco) ↗

Ingegneria della sicurezza

La sicurezza è una scelta architetturale.

Crittografia trasparente, confini di fiducia espliciti e flussi verificabili definiscono VORQYN, dalla password principale fino ai commit autenticati.

Torna alla home ↗