Sabato 25 ottobre 2025 si terrà il 25esimo Linux Day in Italia, la principale manifestazione italiana dedicata al software libero, la cultura aperta ed alla condivisione digitale!
Quest’anno PLUG, LuccaLUG, FLUG e GOLEM uniscono le proprie forze per organizzare un unico grande evento a Prato: proponi il tuo argomento su day.linux.prato.it!
Per i malati del trashware ho voluto replicare il test precedente su un vecchio Pentium Dual-Core E5800 3.20GHz privo di accelerazione aes e con soli 4 GB RAM. In questo caso non ho potuto usare gocryptfs perché supporta come minimo CPU x86-64-v2. Al suo posto, come FS userspace, ho ripiegato per il vecchio EncFS (solo a scopo didattico perché non è più attivamente sviluppato e non è attualmente considerabile sicuro).
Ext4 con fscrypt si è confermato il filesystem con le maggiori performance in scrittura, dm-crypt/LUKS non gli si è discostato di molto e lo ha addirittura superato in quanto a velocità di lettura. EncFS è riuscito a fare meglio solo dello ZFS che purtroppo dopo pochi secondi saturava sistematicamente un core della CPU. Per trasferire 5GB cifrati con un PC di 15 anni fa occorrono (circa) quindi:
Su un PC con CPU Intel i7-4790K (dotata di accelerazione hardware per l’algoritmo di cifratura aes), 16GB di RAM ed hard disk Seagate Barracuda 7200 da 500GB il supporto per la cifratura integrato nel filesystem ext4 è stato quello che si è comportato meglio in assoluto, con velocità in scrittura praticamente identiche a quelle di ext4 con la cifratura disabilitata. dm-crypt/LUKS è stato più veloce di ZFS con file sotto ai 5 GB. gocryptfs come prevedibile, in quanto strumento user-space, è stato il filesystem più lento tra i 4.
Dettagli del test
Sono state create 3 partizioni sul disco:
una formattata con ext4 (con due cartelle da cifrare rispettivamente con FScrypt e gocryptfs),
un volume dm-crypt/LUKS formattato in ext4 # cryptsetup luksFormat --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 /dev/sdc2 # cryptsetup open /dev/sdc2 lukspart # mkfs.ext4 /dev/mapper/lukspart
un pool ZFS col dataset cifrato zpool create tank /dev/sdc3 zfs create -o encryption=aes-256-gcm -o keyformat=passphrase -o keylocation=prompt tank/encrypted_data zfs load-key tank/encrypted_data zfs mount tank/encrypted_data
Ho generato con dd 3 file rispettivamente da 1GB, 5GB e 10GB contenenti bit casuali
Con rsync ho misurato la velocità di trasferimento di questi file nelle varie partizioni o directory cifrate e per confronto anche con la semplice copia in una partizione ext4 non cifrata. Dopo ogni copia, per pulire la cache ho lanciato il comando “echo 3 > /proc/sys/vm/drop_caches”
time rsync --progress testfile1G /mnt/“filesystemcifrato“ time rsync --progress testfile5G /mnt/“filesystemcifrato“ time rsync --progress testfile10G /mnt/“filesystemcifrato“
Velocità in lettura
Per completezza ho misurato anche le velocità di lettura col comando:
Microsoft supporta la cifratura del disco da Windows 7 e da Windows 11 è attivata di default. Anche Linux la supporta da moltissimo tempo e svariati progetti si sono susseguiti o affiancati nel tempo: il pionieristico CFS (1993), loop-AES (2001), cryptoloop (2002), dm-crypt (2003), EncFS (2003) e eCryptFS (2006).
Al momento le principali implementazioni crittografiche opensource disponibili su Linux sono:
dm-crypt/LUKS: tuttora lo standard della crittografia del disco su Linux. Funziona a livello di block device ed è trasparente per il filesystem (stile LVM), permette quindi la cifratura di interi dischi, partizioni o volumi logici.
fscrypt (2016): un framework di crittografia che opera a livello di file e directory anziché di device come LUKS. È integrato direttamente nel filesystem ext4 e F2FS (a “breve” dovrebbe utilizzabile anche su Btrfs). È utile se ci si vuol limitare a proteggere specifiche directory, magari per non sovraccaricare il sistema cifrando l’intero disco.
gocryptfs (2015): a differenza dei precedenti funziona in user-space tramite tramite FUSE. Come FScrypt permette la creazione di directory cifrate, ma al contrario di quest’ultimo non consente l’oscuramento dei metadati (timestamp, permessi).
ZFS (2019): permette di cifrare i dataset (sottovolumi). Purtroppo non essendo integrato nel kernel Linux è supportato nativamente da poche distribuzioni (Gentoo, NixOS, Proxmox…).
Quale scegliere? Se si vuole cifrare l’intero disco probabilmente dm-crypt/LUKS è la scelta ideale, se si utilizza ext4 e ci si accontenta di cifrare solo qualche directory forse è FScrypt l’opzione migliore, se non si può fare a meno di un filesystem moderno come btrfs (che però manca ancora il supporto della cifratura) la soluzione più semplice è qualcosa che operi in user-space come gocryptfs. Se siete abbastanza avventurosi con ZFS potrete godere di una miriade di funzionalità, crittografia compresa.
Ma come si comportano sul campo questi filesystem?
Ho deciso di metterli alla prova su un Seagate Barracuda 7200 da 500GB su un moderno Intel i7-4790K con 16GB di RAM e su un più stagionato Pentium Dual-Core E5800 con 4GB RAM.
C’eravamo lasciati con una domanda: quale fosse il sistema operativo migliore per spremere al meglio quel Pentium 200 con 48MB RAM, hard disk da 2GB e scheda ethernet NE2000.
Il collo di bottiglia di quel bolide era la scheda di rete ISA a 10Mbit e tutti i sistemi operativi provati hanno superato abbondantemente il limite di trasferimento di 900 KB/s di quella scheda, quindi probabilmente anche DOS non ci avrebbe sfigurato. Per dare comunque un senso a questo test, ho installato sulla replica di quel PC una scheda di rete RTL8139C PCI a 100 Mbps ed ho provato a spremerlo con alcuni trai principali OS per server disponibili all’epoca:
Windows 2000 Server: facciamo lo sforzo di fantasia di immaginare uno studente 19enne con $999 da buttare investire per il sistema operativo del suo serverino domestico
Debian Woody 3.0 (kernel 2.4.18): la distribuzione più di cool disponibile in quel momento
Linux Mandrake 9.0 Dolphin (kernel 2.4.19): la distribuzione che usavo sul desktop di tutti i giorni
OpenBSD 3.1: perché davvero la usai su quel PC (anche se non quella specifica versione), per vedere come si comporta un sistema BSD su quell’hardware e perché il suo sistema di base comprende server web ed ftp, così non devo ingrullire a cercare pacchetti su mirror di mirror di mirror sperando che il sysadmin si sia scordato di cancellarli
SCO Openserver 5.0.6: nello stesso mondo immaginario in cui posso spendere due milioni di lire per Windows server non ho difficoltà a tirare fuori un milione e mezzo per acquistare la licenza base dello SCO UNIX
Come avevo già fatto per il test su macchina virtuale, anche qui ho misurato la velocità di trasmissione via http col tool ab con un carico di 100 connessioni simultanee per un totale di 10000 connessioni caricando un documento da 18,6 KB. Per verificare la velocità massima di trasferimento via ftp ho invece eseguito 5 upload e 5 download di un file da 100 MB, ho fatto la media dei tempi e ne ho calcolato la velocità.
Con mia grande sorpresa Windows 2000 ha battuto la concorrenza in 2 prove su 3: distribuzione di pagine html statiche e upload via ftp (apprezzate l’onestà perché avrei potuto insabbiare tutto). Mandrake, pur essendo una distribuzione orientata all’uso desktop, si è comportata molto bene superando Debian in ben 2 prove. La cosa che più mi ha infastidito di Mandrake è stata il suo lunghissimo tempo di avvio: quasi 2 minuti contro i 30 secondi circa di tutti gli altri sistemi operativi. OpenBSD si è difeso bene mantenendo valori intermedi in tutte le prove. SCO Openserver, come già era successo nei test su macchina virtuale, è stato il sistema operativo più lento in tutte le prove. A titolo informativo segnalo che SCO è stato di gran lunga il più lento nel processo di installazione, durato oltre un’ora e mezzo, ed è stato l’unico sistema operativo a non supportare nativamente l’RTL8139.
Classifiche
WEB server 1) Windows 2000 2) Debian Woody 3) Linux Mandrake 9.0 4) OpenBSD 3.1 5) SCO Openserver 5.0.6
FTP-UPLOAD 1) Windows 2000 2) Linux Mandrake 9.0 3) OpenBSD 3.1 4) Debian Woody 5) SCO Openserver 5.0.6