I'm looking for a file encryption algorithm (or library) that supports
efficient random access to the cleartext. That is, given an encrypted
file, I need to be able to repeatedly read arbitrary byte-ranges from
the cleartext with as little overhead as possible.
Ciò che stai chiedendo è altamente dipendente dalla primitiva di crittografia. Non è possibile avere un accesso arbitrario al testo in chiaro senza decrittografare il testo cifrato su ciascun accesso. Per ridurre il sovraccarico, è possibile decodificare l'intero file una volta, memorizzarlo nella cache e utilizzarlo successivamente oppure, in base allo schema di crittografia, memorizzare la quantità minima richiesta di parametri necessari per decrittografare le informazioni necessarie. Ad esempio, i cifrari a blocchi (sicuri) concatenano tutti i blocchi precedenti prima della crittografia di quello corrente. Quindi è sufficiente conoscere l'output del precedente (e la chiave) per decifrare il blocco corrente. Conoscendo la lunghezza del blocco, il vettore di inizializzazione (se utilizzato) e la chiave di decrittografia è possibile memorizzare le uscite di ciascun blocco. Sfortunatamente, nel caso di AES, questo non riduce i requisiti di archiviazione (dato che memorizzerai i dati con la lunghezza dell'intero testo in chiaro). Tuttavia, a seconda dei segmenti del file in uso, è possibile stimare una probabilità di utilizzo e memorizzare solo il testo in chiaro per tali voci. In pratica, è difficile da implementare a causa degli offset (molto) probabilmente diversi di testo e blocchi utili.
This clearly isn't rocket science: I imagine one would do it by
breaking the file into fixed-size chunks and encrypting each chunk
with a symmetric cipher like AES. I'd need to use a different key for
every block (derived by combining a master key and the block offset?),
and I'd want an in-memory LRU block cache for performance. But it's
fiddly enough that I'd much rather use an existing library than design
it myself and run the risk of getting something disastrously wrong.
Sembrerebbe una soluzione di ripiego:
makeshift_crypto.sh
#!/bin/bash
d1="enc/"
d2="dec/"
# Split the file into separate files of 1000 bytes each, suffixed by _bigFile
split -b 1000 bigFile.tar.gz --additional-suffix=_bigFile
# Encrypt each file using aes256 cbc(with salt)
for fl in *_bigFile; do $ openssl enc -aes-256-cbc -salt -in "$fl" -out "$enc""$fl"; done
# Decrypt each file
for fl in 'ls "$enc"'; do openssl enc -aes-256-cbc -d -in "$enc""$fl" -out "$dec""$fl"
If I did have to design this myself, my main question would be key
derivation: is it safe to derive each block's key from a master key
and the block offset -- something like SHA2(masterkey || offset) -- or
do I need to generate a random key for each block? (If the latter,
those keys will need to be stored in the file, which makes it a bit
trickier to keep the file chunks on filesystem block foundaries
No, non è sicuro, poiché ottenere la chiave dal blocco i (è un indice per quel blocco) consentirebbe di recuperare tutte le chiavi rimanenti n - i dove n è il numero di chiavi (blocchi) e 0 < = i < n . La complessità della gestione delle chiavi aumenta anche con il numero di blocchi. È sicuro usare una sola chiave per tutti (come faresti se criptassi / decifri il file interamente).