Re: [OT] Consiglio per cifratura file

Il 10/02/25 14:20, Gerlos ha scritto:
> Imho prima di tutto dovresti fare qualche prova e scegliere se vuoi 
> usare un sistema di crittografia stacked o a blocchi:
> 
> - Stacked: i file vengono criptati individualmente nel volume criptato, 
> se modifichi un file deve essere ri-trasmesso solo quello, e non 
> l'intero volume criptato. È possibile desumere informazioni sui file 
> esaminando  dimensioni e orario di modifica dei file criptati. In 
> generale continua a funzionare anche se si "rompe" qualcosa durante un 
> trasferimento (al peggio perdi il singolo file interessato).
> 
> - A blocchi: i file sono contenuti in un intero blob criptato, che può 
> venir modificato in modo imprevedibile, e che deve essere elaborato 
> nella sua interezza prima di essere trasmesso. È più sicuro perché non 
> c'è modo di sapere nulla sui metadati dei file contenuti. Ma non è detto 
> che questo sia rilevante per il tuo caso d'uso. Occhio che se qualcosa 
> va storto durante il trasferimento potresti trovarti con l'impossibilità 
> di montare l'intero volume!
> 
> Uscendo dal ragionamento paranoico, a seconda di che dati tieni e dove 
> li tieni, i vantaggi di un sistema meno sicuro ma più adatto alla 
> trasmissione via rete possono superarne gli svantaggi.
> 
> In definitiva io proverei a implementare entrambi e vedrei quale dei due 
> finisce prima il trasferimento, impiegando meno risorse, e quale è più 
> "robusto" in caso di problemi di connettività o se il processo di 
> trasferimento viene killato per qualche ragione.
> 
> saluti,
> Gerlos
> 
> 

Ciao Gerlos e grazie per la risposta,

Il motivo per cui gocryptfs è uno dei due candidati è proprio per il 
fatto che ogni singolo file viene cifrato senza creare un blob unico. 
gocryptfs è nato proprio per ottimizzare il trasferimento su cloud. Ho 
fatto molte prove con file cifrati con gocryptfs ed in ogni caso il 
danno è limitato al singolo file, o per esempio corruzione dell'IV di 
una directory si perdeva la directory (ma se hai l'IV backuppato e lo 
ripristini problema risolto, inoltre si può recuperare il contenuto dei 
file con una procedura ma non il nome del file). La sincronizzazione 
remota di un volume gocryptfs con rsync è come sincronizzare un 
directory normale con rsync. È molto semplice da usare, monti, usi e 
smonti (e se non smonti ha un timeout in cui se il volume non viene 
usato per N tempo lo smonta automaticamente). Inoltre l'overhead di 
gocryptfs è certamente minore rispetto al container LUKS.

Il motivo per cui LUKS file container è il secondo candidato è perche è 
integrato in Linux in maniera profonda ed è testato. Ma devo dire che ho 
riscontrato diversi svantaggi nell'uso dopo svariato tempo di utilizzo, 
dei file container:

1) È più complicata/lunga l'inizializzazione a gocryptfs. Per 
quest'ultimo basta inizializzare la directory che si vuole, montarlo e 
usarlo mentre con il file container dovrei allocare il file e preservare 
spazio con fallocate, poi per buona pratica questo file dovrebbe essere 
riempito di valori urandom per non far identificare dove sono i dati 
cifrati (e questo richiede tempo soprattutto se un file container è 
grosso qualche centinaio di GB), poi devo formattarlo per LUKS 
scegliendo un cipher, un iteration time (se l'iteration time è 
abbastanza lungo si ha una maggiore prevenzione sul bruteforce perche 
aumenta l'entropia ma aumenta anche il tempo di apertura del volume, 
quindi devi trovare un compromesso per le prestazioni), hash, pbkdf, 
eccc, poi devo aprirlo con 'luksOpen', creare sul device virtuale un fs 
come ext4 (o xfs o btrfs) e chiuderlo.

2) Nel mio caso di utilizzo dovrebbe essere preferito avere l'header 
distaccato dal file container nel caso di salvataggio remoto (basta un 
cryptsetup luksDump file.img e ti spara fuori un sacco di cose e non 
richiede la chiave per avere queste info). Qui nasce un altro problema: 
se hai l'header distaccato devo backupparlo regolarmente perche se lo 
perdi o è corrotto addio al volume cifrato (non credo ci sia un modo per 
recuperarlo o rigenerarlo).

3) Utilizzo macchinoso. Per usare un LUKS file container devi aprire il 
device LUKS , montare l'fs, usare il device, smontare l'fs e chiudere il 
device (sempre che l'header sia intatto, che la chiave sia intatta e che 
il file container sia intatto, che il filesystem sul file container sia 
intatto).

4) Come hai detto giustamente, viene creato un file blob e se viene 
corrotto, chissà se mai si riesce a riaprirlo, montarlo ecc.... (Non ho 
ancora provato a corrompere un Luks file container)

5) Overhead sull'utilizzo. Qui ci tengo a precisare che non ho fatto 
misurazioni tecniche in modo tale da avere una netta distinzione, ma da 
alcune prove di scrittura con dd c'è un calo di prestazioni dovuto ai 
diversi strati.

6) Troppo strati da gestire: disco fisico,(altri strati come mdadm o 
LVM, o VDO), FS, luks, FS. Per non parlare del problema di usare FS COW 
uno sopra all'altro tipo XFS (ok non è completamente COW) o btrfs o un 
mix (tipo host su zfs/btrfs e container su xfs) e si va in write 
amplification (che su SSD è pessimo per non parlare del degrado di 
prestazioni)

7) fallocate su un filesystem COW come ZFS e btrfs con compressione 
attiva è un delirio perche non permette di riservare spazio 
correttamente. Con fallocate il file viene visto pieno di \0 e su ZFS lo 
comprime all'osso (non ho provato con btrfs ma credo sia uguale) quindi 
bisognerebbe riempirlo di valori casuali con /dev/urandom ma anche in 
questo caso non è assicurato che n Gb vengano riservati per via della 
compressione. Il problema non è di fallocate ma di luks che richiede cmq 
uno spazio definito su cui lavorare. Giustamente è stato progettato per 
device e non file.

8) A volte potrebbe essere necessario aumentare la dimensione del file 
container e anche qui risulta complesso e rischioso. Praticamente 
bisogna riservare altro spazio con fallocate (cercando di non cancellare 
il vecchio), fare il resize del luks, aprire il device, fare il resize 
dell'fs (nel caso di XFS bisogna montare l'fs prima del resize, nel caso 
di ext4 se montato va fatto online se non montato richiede che il 
filesystem sia marcato come 'clean' quindi richiede e2fsck -f /dev/...) 
e via dicendo

Non ho fatto molte prove di trasferimento con rsync del LUKS file 
container, ho notato solo che con rsync e destinazione remota utilizza 
il delta-transfer per minimizzare i dati da trasferire. Con gocryptfs è 
come sincronizzare una semplice dir. Posso dire che se il processo di 
trasferimento viene killato con LUKS file container potrei ritrovarmi 
con un blob non utilizzabile/corrotto e con gocryptfs (quasi 
sicuramente) solo il file che sta trasferendo riporterebbe un problema 
(ma il resto del dataset rimane accessibile)

Al momento sto preferendo gocryptfs per i motivi sopra riportati (anche 
perche con LUKS file container si complica troppo). Se qualcuno ha 
esperienza su LUKS file container e ha consigli da darmi per risolvere i 
problemi riportati sono a disposizione.

Se ho detto cappe---te chiedo scusa in anticipo.

Saluti, Alessandro.