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.
