Ho ricevuto Crypt-in — Market Audit v10. È un documento pubblico strutturato come market audit, technical positioning paper e base per la due diligence, con una distinzione chiara tra prodotto esistente, roadmap, threat model, limiti, pricing, rischi e proiezioni.

Quale risultato vuoi ottenere: audit critico, fact-check tecnico e competitivo, riscrittura editoriale, versione investor-ready, executive summary, oppure impaginazione in PDF/documento professionale?

Audit critico — Crypt-in Market Audit v10

Verdetto

Il documento è molto più credibile della media dei pitch pre-prodotto: distingue ciò che esiste dalla roadmap, ammette i limiti del threat model, evita proiezioni eccessive e riconosce che il moat oggi non è ancora costruito.

Tuttavia, non è ancora pronto per una due diligence tecnica o per essere distribuito come documento “verificabile”. La promessa centrale presenta contraddizioni tra seed, root secret, GET_SECRET, master secret del Vault e chiavi di sessione. Inoltre, “zero-knowledge”, “irreversibile”, “nessun altro” e “decifrabili per sempre” sono formulazioni più forti di quanto l’architettura descritta possa dimostrare.

Valutazione indicativa di readiness per investitori: 44/100.
Non è un voto al prodotto; è un voto alla solidità delle prove disponibili nel documento.

I tre blocchi principali

1. “Il segreto non lascia mai il dongle” non è coerente con l’architettura descritta

Il documento afferma contemporaneamente:

• che il segreto radice non lascia mai il chip;
• che esiste un comando GET_SECRET;
• che il Vault esegue CMD_GET_SECRET → master secret in RAM;
• che il seed BIP-39 consente di ricostruire integralmente il dongle.

Queste affermazioni non possono essere tutte vere con il significato ordinario dei termini.

Se GET_SECRET esporta una chiave persistente sufficiente a decifrare i documenti, una chiave crittografica di lungo periodo lascia il dongle. Se esporta soltanto una chiave di sessione, il comando deve essere rinominato e la derivazione deve essere documentata formalmente.

Anche il seed costituisce un’eccezione importante. Una frase mnemonica BIP-39 a 24 parole codifica l’entropia necessaria alla ricostruzione del segreto: durante il setup, questa informazione viene necessariamente mostrata all’utente e quindi lascia il chip in forma di backup umano. BIP-39 definisce proprio la trasformazione dell’entropia, con checksum, in una frase mnemonica. (GitHub)

La formulazione difendibile sarebbe:

La chiave radice binaria non è esportabile attraverso le normali API del dispositivo. Durante l’inizializzazione, l’utente riceve una rappresentazione mnemonica di recovery sotto il proprio controllo. Le operazioni ordinarie esportano esclusivamente chiavi operative derivate e limitate alla sessione.

Prima di qualsiasi audit servono nomi non ambigui:

text
K_recovery       seed recuperabile tramite BIP-39
K_identity       identità crittografica recuperabile dell’utente
K_attestation    identità unica del dispositivo fisico, non recuperabile
K_file           chiave casuale per singolo file
K_session        chiave effimera host-dongle
K_vault          chiave o KEK del Vault

GET_SECRET dovrebbe diventare qualcosa come DERIVE_SESSION_KEY, con input, output, dominio HKDF e durata esplicitamente definiti.

2. Recovery deterministico e modello di licenza sono in conflitto

Il recovery promette:

text
stesso seed → dongle identico → stessa pubkey → tutti i file accessibili

Questo implica che lo stesso seed può essere caricato su più ESP32-S3 contemporaneamente. Se la licenza è legata esclusivamente alla pubkey derivata dal seed, tutti i dongle clonati appariranno al license server come lo stesso dongle.

Non esiste una differenza crittografica tra:

• un legittimo dispositivo di sostituzione;
• una seconda copia di backup;
• dieci copie non autorizzate.

Il problema è ancora più serio per il programma LPN e per il firmware DIY. Una pubkey Ed25519 generata su un ESP32 è indistinguibile da una pubkey generata da un emulatore software, a meno che esista una catena di attestazione del dispositivo. Il protocollo pubblico e la keypair generata al primo avvio non dimostrano che dietro la pubkey ci sia hardware autentico.

La soluzione è separare due livelli:

1. Identità di cifratura recuperabile, derivata dal seed e necessaria per non perdere i dati.
2. Identità di attestazione fisica, generata e certificata per ogni dispositivo, non recuperabile e non utilizzata direttamente per cifrare i file.

In caso di recovery, il license server dovrebbe trasferire l’entitlement a una nuova identità fisica, revocare quella precedente o applicare un numero massimo di dispositivi.

Questa separazione è indispensabile. Senza di essa, bisogna dichiarare apertamente che la licenza è legata a una identità crittografica clonabile, non a un singolo dongle.

3. Il Vault non è “zero-knowledge” nel senso normalmente utilizzato dal mercato

Il Vault porta il master secret, o una chiave equivalente, nella RAM del server e decifra i documenti sul server. Durante una sessione attiva:

• il server vede il plaintext;
• un amministratore del sistema sufficientemente privilegiato può potenzialmente accedervi;
• malware, debugger, crash dump, snapshot della VM o compromissione dell’host possono acquisire chiavi o contenuti.

Questo può rendere lake8.dev incapace di decifrare i dati, ma non rende il sistema end-to-end zero-knowledge rispetto al server del cliente.

La terminologia più precisa è:

• vendor-blind;
• provider-inaccessible;
• lake8.dev non possiede materiale di decifratura;
• customer-controlled key custody.

La tabella competitiva su Nextcloud è inoltre troppo categorica. Nextcloud distingue server-side encryption, dove le chiavi sono sul server, ed end-to-end encryption, dove soltanto i client possono decifrare. Quindi “Nextcloud: zero-knowledge ❌” è incompleto: è vero per la modalità SSE, ma non descrive la modalità E2EE ufficialmente supportata. (Nextcloud)

Tresorit dichiara invece un sistema end-to-end e zero-knowledge su tutte le principali piattaforme. Il confronto deve includere non solo il prezzo, ma collaborazione, condivisione, recovery amministrativo, data residency, supporto e certificazioni. (Tresorit)

Problemi tecnici ad alta priorità

Il formato .crin è troppo incompleto per essere considerato una specifica

Il formato indicato contiene:

text
MAGIC + VERSION + PUBKEY + SALT + NONCE + CIPHERTEXT + TAG

Mancano almeno:

• identificatore dell’algoritmo;
• identificatore e parametri della KDF;
• schema di derivazione della chiave;
• autenticazione dell’intero header come AAD;
• strategia di chunking per file grandi;
• indici e nonce per ogni chunk;
• dimensione originale;
• gestione dei file troncati;
• eventuale file key cifrata o wrapped;
• compatibilità futura e policy di migrazione;
• test vector normativi;
• regole per rename e metadata.

AES-GCM supporta authenticated associated data, ma il documento non dice se MAGIC, versione, pubkey, salt e metadata siano autenticati. NIST definisce GCM come modalità AEAD: l’utilizzo corretto dell’IV e dell’AAD fa parte del protocollo, non è un dettaglio implementativo. (NIST CSRC)

Serve una specifica simile a:

text
Fixed header
Authenticated metadata
Wrapped random file key
Chunk 0: nonce derivato + ciphertext + tag
Chunk 1: nonce derivato + ciphertext + tag
...
Final authenticated manifest

Il file dovrebbe utilizzare una chiave casuale distinta per ogni oggetto, non una chiave di lunga durata direttamente con un nonce casuale.

memset_s() e mlock() non bastano a dimostrare la cancellazione

La cancellazione dalla RAM è una misura utile, ma non consente di promettere irreversibilità su un sistema general purpose.

Bisogna considerare:

• copie create dal garbage collector;
• stringhe immutabili in .NET;
• buffer duplicati dalle librerie;
• crash dump e core dump;
• page cache;
• hibernation;
• snapshot della VM;
• memoria dell’applicazione browser;
• clipboard e thumbnail;
• copie effettuate mentre il Vault era aperto.

NIST definisce la zeroization come distruzione tale da impedire il recupero del valore; ottenere questa proprietà in un’applicazione desktop o in un container richiede controllo dell’intero ciclo di vita dei buffer, non soltanto una chiamata finale a memset_s(). (NIST CSRC)

La frase di chiusura:

“Fisico, immediato, irreversibile.”

deve essere rimossa. La forma difendibile è:

La rimozione del dongle revoca la capacità del sistema di effettuare nuove decifrature e avvia la cancellazione delle chiavi operative. Non può revocare copie del contenuto già create durante una sessione autorizzata.

Il proximity lock descritto è fail-open

Il flusso attuale dice:

text
dongle fuori range
→ conferma PIN
→ Vault chiede conferma prima di chiudersi

Un controllo di sicurezza non dovrebbe chiedere conferma prima di attivarsi. Se il segnale viene considerato affidabile dopo l’hysteresis:

text
dongle fuori range
→ Vault si blocca
→ PIN necessario per annullare o riaprire

Inoltre, BLE RSSI non dimostra presenza fisica: relay, interferenze, variazioni ambientali e batterie scariche devono essere inclusi nel threat model. La decisione corretta di non considerarlo kill switch primario va mantenuta.

Il threat model esclude proprio l’attacco più probabile durante l’utilizzo

Crypt-in protegge bene un dispositivo spento o un file esfiltrato mentre è cifrato. Ma quando il dongle è inserito, un processo locale potrebbe provare a inviare comandi HID.

Servono almeno:

• user presence fisica o conferma esplicita;
• PIN locale con rate limiting;
• autorizzazione per operazione o sessione;
• binding tra processo autorizzato e sessione;
• timeout breve;
• protezione contro replay e downgrade;
• audit log locale;
• separazione fra “dongle presente” e “utente consenziente”.

Altrimenti il dongle diventa una chiave lasciata nella serratura: protegge quando assente, ma qualsiasi malware attivo durante la sessione può tentare di usarlo.

Docker e Kubernetes non sono la stessa architettura operativa

“Da Raspberry Pi a Kubernetes senza modifiche al codice” è una frase troppo forte.

In Kubernetes servono tipicamente:

• device plugin o host agent;
• node affinity;
• gestione del pass-through USB;
• privilegi e capability per mlock;
• comportamento in caso di pod restart;
• gestione dei nodi sostitutivi;
• high availability;
• backup e rotazione delle chiavi;
• strategia per più dongle;
• comportamento quando il dongle è collegato a un nodo diverso.

Un singolo dongle collegato a un singolo nodo crea un single point of failure incompatibile con l’aspettativa tipica di un deployment enterprise. La roadmap dovrebbe essere:

text
Vault single-node Docker
→ host security agent
→ multi-node con key shares
→ Kubernetes certificato

Hardware e firmware

L’ESP32-S3 supporta effettivamente Secure Boot v2, flash encryption, eFuse e disabilitazione del debug; questo rende credibile il threat model commodity dichiarato. Non lo rende però equivalente a un secure element certificato. (Espressif Systems)

Esiste anche una conseguenza operativa rilevante non presente nel documento: abilitando Secure Boot o flash encryption, lo stack USB-OTG in ROM non consente più l’aggiornamento tramite normale DFU su quella porta. La strategia di aggiornamento firmato, recovery da firmware corrotto e gestione dei dispositivi brickati deve quindi essere definita prima della produzione. (Espressif Systems)

L’appendice associa inoltre Monocypher ad AES-256-GCM. La documentazione Monocypher descrive come AEAD principale ChaCha20-Poly1305; se AES-GCM proviene da una seconda libreria o dall’ESP-IDF, questa deve essere nominata, versionata e inclusa nell’audit. (monocypher.org)

Mancano inoltre:

• processo di provisioning degli eFuse;
• gestione e rotazione della chiave di firma firmware;
• firmware rollback protection;
• secure update;
• dispositivi di test separati da quelli production;
• gestione di un errore durante il burning degli eFuse;
• verifica che chiavi e plaintext non finiscano nella PSRAM esterna;
• politica di vulnerability disclosure;
• SBOM firmware.

Il paper MDPI è presentato in modo eccessivo

Il paper citato esiste ed è stato pubblicato nell’aprile 2026. Descrive una hardware key basata su ESP32-S3 per esternalizzare controlli e operazioni crittografiche da un’applicazione host. (MDPI)

Non è però una “validazione indipendente dell’architettura Crypt-in” per come è descritta nel documento. Non valida necessariamente:

• il protocollo Crypt-in;
• GET_SECRET;
• il formato .crin;
• il recovery BIP-39;
• il Vault;
• il kill switch;
• il canale BLE;
• la sicurezza contro fault injection;
• il modello di licenza.

La frase corretta è:

Il paper fornisce evidenza accademica della fattibilità generale di hardware key basate su ESP32-S3; non costituisce un audit o una validazione di Crypt-in.

Audit e roadmap: contraddizione interna

Il documento stabilisce che la “prova di sicurezza” deve precedere Mobile, Vault, SDK Swift ed espansione. Ma la roadmap colloca:

• Mobile e Vault a 12–18 mesi;
• audit pubblico nell’anno 2 o successivo.

Le due sezioni sono incompatibili.

Per un prodotto la cui proposta di valore è la sicurezza, l’audit del protocollo e del firmware dovrebbe essere pre-lancio pubblico o immediatamente precedente alla prima vendita, almeno con scope limitato:

1. key hierarchy;
2. protocollo USB;
3. formato .crin;
4. recovery;
5. firmware security configuration;
6. updater.

L’audit completo del Vault può seguire quando il Vault esiste.

Il budget di €20.000 equivale a circa il 32% del ricavo totale previsto per l’anno 2 e supera l’intero ricavo previsto per l’anno 1. Non è un problema in sé, ma dimostra che le proiezioni non finanziano autonomamente la roadmap: serve capitale del fondatore, finanziamento esterno o una roadmap più stretta.

Analisi competitiva

Nextcloud

La critica alla server-side encryption è fondata: le chiavi SSE sono gestite dal server e quella modalità non protegge da un server compromesso. Ma Nextcloud offre anche E2EE client-side. La tabella deve separare:

Nitrokey

È corretto considerare Nitrokey un concorrente parziale. Nitrokey documenta integrazioni con VeraCrypt e LUKS; la stessa documentazione avverte che l’integrazione VeraCrypt basata su keyfile non sfrutta pienamente le proprietà della smart card e può esporre il keyfile a un host compromesso. Questa è una differenza competitiva utile, ma va descritta con precisione. (Nitrokey Documentation)

GuardKey e Changingtec

“Zombie 2016” è una definizione non sufficientemente dimostrata. Changingtec mantiene un sito attivo e pagine di download che includono prodotti GuardKey, anche se questo non prova che il prodotto abbia uno sviluppo moderno o un mercato significativo. La definizione dovrebbe essere sostituita con dati verificabili: data ultima release, compatibilità OS, disponibilità commerciale e attività di supporto. (Changing Tec)

“Questo non lo fa nessun altro”

È una pretesa quasi impossibile da provare globalmente.

Meglio:

Nella ricerca competitiva svolta a luglio 2026 non abbiamo identificato un prodotto direttamente comparabile che combini dongle commodity recuperabile, formato portabile, self-hosting e revoca fisica delle chiavi del server.

La ricerca dovrebbe avere un’appendice con:

• query utilizzate;
• database consultati;
• data della verifica;
• criteri di inclusione;
• concorrenti esclusi e motivo.

Modello commerciale ed economico

Personal

L’obiettivo di 200 clienti produce correttamente €6.000 annui a €30 ciascuno. Ma il prezzo percepito del primo anno per un cliente Kit Standard è:

text
€40 kit + €15 spedizione + rinnovo/licenza

La proposta va confrontata sul costo totale del primo anno, non soltanto sui €30 annui.

Il blocco della nuova cifratura alla scadenza è eticamente positivo, ma può generare un comportamento economicamente razionale: cifrare molti file durante l’anno, cancellare l’abbonamento e continuare a decifrarli. Il modello deve misurare:

• frequenza di nuova cifratura;
• tasso di riattivazione;
• valore degli aggiornamenti;
• costo del supporto per utenti non più paganti.

La promessa “decifrabili per sempre” è inoltre troppo assoluta con app e firmware chiusi. Per renderla credibile serve almeno uno dei seguenti:

• decryptor offline pubblico;
• reference CLI open source;
• certificato di licenza perpetuo per la sola decifratura;
• protocollo e formato completi con test vector;
• piano di continuità nel caso lake8.dev cessi l’attività.

Kit

“Chip da €5” non equivale a costo prodotto di €5. Mancano dal modello:

• PCB o development board;
• connettore e cavi;
• case;
• powerbank;
• seed card;
• assemblaggio;
• provisioning;
• test;
• imballaggio;
• resi;
• sostituzioni;
• IVA;
• commissioni;
• conformità;
• supporto.

Il Kit Pro con BLE è radio equipment. La commercializzazione europea richiede valutazione di conformità e applicazione della normativa pertinente, inclusa la Radio Equipment Directive e la marcatura CE. (Internal Market SME)

Vault

€100 al mese per cinque utenti è probabilmente un prezzo insufficiente se include onboarding, supporto, gestione degli incidenti e assistenza Docker. Il pricing dovrebbe separare:

text
licenza annuale
+ onboarding
+ supporto standard/premium
+ eventuale appliance o dongle di backup
+ servizi professionali

Per studi legali ed enti pubblici, il costo di vendita e procurement può superare largamente il valore del primo anno del contratto base.

SDK e LPN

“Open source con registrazione email obbligatoria per il download” non è un controllo sostenibile. Se il codice è realmente open source può essere copiato, mirrorato e redistribuito senza passare dal form.

La registrazione può essere richiesta per:

• binari firmati;
• supporto;
• chiavi sandbox;
• documentazione enterprise;
• programmi partner.

Non per controllare efficacemente chi utilizza il sorgente pubblico.

L’8% LPN potrebbe essere insufficiente per motivare un rivenditore che deve assemblare, supportare, fatturare e assumersi rischio reputazionale. Deve essere validato con interviste reali a ISV, non scelto soltanto per proteggere il margine.

Proiezioni: non ancora un modello finanziario

Le tabelle riportano ricavi, ma non consentono di valutare il business.

Mancano:

• unità vendute per prodotto;
• clienti iniziali e nuovi clienti;
• churn e retention;
• ricavi one-off contro ricorrenti;
• eventuale doppio conteggio fra Personal e LPN;
• costo hardware;
• costo spedizione;
• costo supporto;
• pagamento e fatturazione;
• VAT;
• refund e chargeback;
• code signing;
• conformità hardware;
• audit;
• assicurazione;
• consulenza legale;
• personale e contractor;
• cash flow.

La metrica “50 rinnovi anno 2” è ambigua. Se riferita ai 200 clienti dell’anno 1, rappresenta soltanto il 25%. Deve essere espressa come:

text
Gross retention
Revenue retention
Cohort renewal rate
Activation-to-paid conversion
Recovery success rate
Support tickets per user

Compliance: oggi è trattata soprattutto come opportunità, non come costo

Il Cyber Resilience Act è correttamente citato come driver di mercato, ma sarà anche un obbligo operativo per hardware e software commercializzati nell’UE. Il CRA riguarda prodotti hardware e software con elementi digitali; dal 11 settembre 2026 entrano in vigore gli obblighi di segnalazione delle vulnerabilità attivamente sfruttate e degli incidenti gravi. (Digital Strategy)

Per un lancio nel 2026 servono quindi già:

• canale security contact;
• processo PSIRT;
• vulnerability disclosure policy;
• gestione CVE;
• SBOM;
• secure update;
• periodo di supporto dichiarato;
• incident reporting;
• documentazione tecnica di conformità.

Per iOS, la crittografia richiede inoltre una valutazione di export compliance e, quando necessario, documentazione specifica in App Store Connect. Apple non garantisce nel materiale ufficiale una finestra generale di review di “4–8 settimane”; quel numero dovrebbe essere indicato come assunzione progettuale, non come regola. (Apple Developer)

La “categoria merchant Stripe” non dovrebbe essere descritta come una categoria nominale da negoziare. Stripe utilizza merchant category code e valutazioni di rischio; è corretto ottenere una pre-clearance, ma va documentata come approvazione dell’attività commerciale e del modello di prodotto. (Stripe Docs)

Correzioni obbligatorie per la v11

1. Eliminare o ridefinire GET_SECRET.
2. Pubblicare la key hierarchy completa, con derivazioni e domain separation.
3. Separare recovery identity e hardware attestation identity.
4. Definire il comportamento dei dongle clonati dallo stesso seed.
5. Rinominare “zero-knowledge” in “vendor-blind” per il Vault.
6. Pubblicare una vera specifica .crin, con AAD, chunking e test vector.
7. Rimuovere “irreversibile”, “immune” e “nessun altro”.
8. Spostare l’audit del protocollo prima del lancio, non nell’anno 2.
9. Correggere le tabelle Nextcloud, Nitrokey e GuardKey.
10. Aggiungere BOM, compliance e cash-flow model.
11. Descrivere la strategia di firmware update dopo secure boot.
12. Garantire la decifratura perpetua tramite un decryptor indipendente dal license server.
13. Limitare il Vault iniziale a single-node Docker.
14. Aggiungere user presence/PIN alle operazioni sensibili.
15. Riposizionare il paper MDPI come evidenza di fattibilità generale.

Decisione raccomandata

Go per:

• Personal Windows in closed alpha;
• protocollo e formato congelati;
• test di recovery;
• dieci test con professionisti non tecnici;
• piccoli pilot paganti.

No-go, allo stato attuale, per:

• claim “zero-knowledge garantito”;
• vendita enterprise del Vault;
• programma LPN;
• dichiarazione “il segreto non lascia mai il dongle” senza eccezione;
• distribuzione del documento come prova tecnica;
• espansione mobile prima dell’audit.

La tesi di prodotto resta interessante. Il vero rischio non è che l’idea sia debole: è che una promessa narrativa molto forte venga pubblicata prima che nomenclatura, recovery, licensing e protocollo siano coerenti tra loro. Una volta risolti questi quattro elementi, il documento può passare da pitch credibile a materiale seriamente difendibile.