Applicazione del delta file a un file crittografato

7

Sto sviluppando un software che verrà utilizzato per il backup dei dati.

Il server funzionerà su Linux. La sicurezza nel trasporto non è un problema (HTTPS o SSH), ma i dati devono essere memorizzati crittografati sul server.

I dati non sono legati a un singolo computer, quindi più computer dovrebbero essere in grado di accedere agli stessi dati, se forniti di una chiave (la chiave condivisa è accettabile).

Il cliente deve essere certo che i dati non possono essere visualizzati sul server, da un dipendente curioso o da un hacker. Ciò significa che il server non deve memorizzare la chiave utilizzata per decifrare la crittografia, ma potrebbe usarla in una transazione se necessario.

Essendo un file server, la rete sarà saturata, quindi l'invio di delta è preferibile rispetto all'invio di interi file. I file saranno anche gestiti (sul server) da un sistema di controllo della versione; mentre il cliente può o non può avere il controllo della versione. Lo spazio è una considerazione.

Questo è quello che mi è venuto in mente:

  • Ogni utente ha il proprio punto di mount
  • Ogni punto di montaggio sarà crittografato
  • I file verranno decodificati, applicando il delta, quindi crittografato nuovamente

Sembra un po 'inefficiente, quindi sono venuto qui per una guida.

I file delta possono essere applicati a un file crittografato?

I requisiti più importanti sono:

  • Integrità dei dati (gli aggiornamenti non dovrebbero mai interrompere un file)
  • Riduci al minimo l'overhead di rete / archiviazione (conservare CPU / ram sarebbe bello, ma non necessario)
  • Deve essere possibile controllare la versione
posta beatgammit 27.08.2011 - 05:50
fonte

6 risposte

10

Non ancora. In pratica stai descrivendo la crittografia omomorfica.

Fondamentalmente si ha un file f che si cripta con la funzione E () indicata come E (f).

Ora disponi di delta che cripti con la funzione E () indicata come E (d).

Vuoi che il nuovo file f 'sia uguale a f con il delta applicato: f' = f + d

Solo tu non vuoi decriptare né E (f) né E (d).

Vuoi E (f) + E (d) = E (f ').

E questa è la crittografia omopica, ma non è ancora pronta per la produzione. Esistono crittosistemi parzialmente omomorfici, ma non sono sicuro che il delta del file si adatti a uno qualsiasi dei sistemi. C'è un cryptosystem completamente omomorfo in fase di sviluppo presso IBM, ma richiede una buona quantità di potenza di calcolo e memoria ed è ancora lento per problemi di grandi dimensioni.

La pagina di IBM Research sulla crittografia omomorfica link

Tesi di dottorato di Craig Gentry " Crittografia completamente omomorfica con reticoli ideali " Questa è una carta da sfondare.

Prima della tesi di Gentry c'erano sistemi completamente omomorfici ma quei sistemi non potevano essere resi pratici. Alcuni sistemi crittografici esistenti, ad esempio RSA, sono parzialmente omomorfici, il che significa che il lavoro omomorfico funziona per una sola operazione (moltiplicazione ad esempio) ma non l'altra (aggiunta). Inoltre si degradano e possono eseguire solo un numero limitato di operazioni omomorfiche prima di causare errori.

La svolta di Gentry è stata quella di stabilire il bootstrap. Nella mia comprensione limitata, il bootstraping stabilisce uno struture nascosto in grado di mantenere la sua coerenza attraverso le operazioni.

Nel maggio del 2011 " Codifica completamente omomorfica senza bootstrap " è stato pubblicato per portare la crittografia omomorfica un passo più vicino al reale uso.

    
risposta data 27.08.2011 - 09:32
fonte
7

Che dire mantenere la linea di base crittografata e non modificata e crittografare e archiviare separatamente i delta? Quando un utente vuole una versione particolare del file, avrebbe bisogno della linea di base e di tutti i delta fino a quel punto. Questo sarebbe abbastanza vicino allo spazio ottimale e ottimizzato per la rete per le scritture dal punto di vista del file server, ma richiederebbe ulteriore spazio di archiviazione sul lato client e larghezza di banda della rete per le letture. Poi di nuovo, una volta che un client viene aggiornato, anche le future letture sono ottimizzate per la rete. Il client è libero di utilizzare uno spazio aggiuntivo per migliorare le prestazioni in modi che dovrebbero essere abbastanza ovvi.

È anche possibile memorizzare set delta cifrati, in cui un client con la chiave unisce alcuni delta e crittografa il risultato, come modo per accelerare il carico iniziale da parte del client. Questo potrebbe essere fatto in modo intelligente per fare meglio di quanto l'approccio ingenuo porterebbe a, in termini di rete e spazio sulle scritture, e in ogni caso, sarebbe efficiente in termini di spazio e di rete sulle letture.

L'ottimizzazione dipende dalle caratteristiche dell'app.

Dichiarazione di non responsabilità: lo sto solo inventando mentre vado qui; Non ho idea se ho descritto l'idea di qualcun altro o qualcosa del genere.

    
risposta data 27.08.2011 - 23:42
fonte
4

Oltre al crittosistema omomorfico (che RSA è parzialmente uno), il tuo secondo requisito potrebbe essere raggiungibile a seconda di come crittografare i dati in primo luogo.

Supponendo che si usi il cifrario a blocchi in modalità ECB, ogni blocco è indipendente da tutti gli altri. Ciò significa che sei libero di decifrare e criptare ogni singolo blocco da solo. Ciò consentirebbe di applicare il delta a ciascun blocco in modo appropriato. La modalità CTR è anche una modalità possibile qui. Per il miglior risultato, tuttavia, consiglierei la modalità ESSIV. Vedi link . Tutto ciò presuppone che tu sappia esattamente quale settore modificare.

Il tuo primo e terzo requisito non sono realmente risolvibili con la sola crittografia. Pensa al guasto del disco a metà dell'aggiornamento. Ovviamente la scrittura fallirà, procurando un errore di integrità.

D'altra parte, perché non usi il disco criptato (come dm-crypt) e lo monti su richiesta, modifichi i file e infine lo smonti?

    
risposta data 27.08.2011 - 14:14
fonte
3

Hai alcuni file di testo in chiaro locali sensibili, si desidera conservare una copia di backup di (versioni crittografate di) quei file su qualche server remoto, hai una larghezza di banda di rete limitata, e vuoi impostare le cose in modo che se il server viene compromesso dai cattivi, non possono leggere il testo in chiaro dei tuoi file.

Sembra esattamente la situazione in cui rsyncrypto è stato progettato per gestire:

Sometimes it is necessary to store files on a remote server for backup purposes.

How do you keep the privacy of files stored on a remote server? Encrypt the files prior to sending them. Keep the key locally.

How do you keep the bandwidth usage to a minimum? Use rsync to only transfer the changes.

There is just one problem - the two solutions contradict.

rsyncrypto comes to the rescue.

With rsyncrypto, both objectives can be achieved simultaneously.

- leggermente parafrasato dalla rsyncrypto home page

The rsyncrypto algorithm ensures that two almost identical files, when encrypted with rsyncrypto and the same key, will produce almost identical encrypted files. This allows for the low-overhead data transfer achieved by rsync while providing encryption for secure transfer and storage of sensitive data in a remote location.

- da Wikipedia: variazioni rsync

Domande correlate: "Esiste un sistema di controllo della versione crittografato?" e "Come fare un backup crittografato simile a rsync?"

    
risposta data 12.06.2012 - 20:24
fonte
2

Il problema principale che devi risolvere è qualcuno che compromette il sistema di controllo della versione. La mia impressione è che il VCS non sia criptato in quanto è responsabile della memorizzazione del testo in chiaro, ma prima della trasmissione viene crittografato. Se questo non è il caso di ignorare la mia precedente dichiarazione. Indipendentemente dall'applicazione di diffs ai file binari è piuttosto intenso e provoca un enorme sovraccarico in termini di requisiti di spazio. Questo può fornire alcune informazioni extra

Aggiornamento per commentare

The version control will only be on the server end (git style preferably, but others work too).

Il mio commento iniziale continua a essere vulnerabile.

The main focus is that I (as the admin) should never be able to read someone else's data

La crittografia lo gestirà, utilizzando un algoritmo basato sul reticolo, che è presumibilmente immune agli algoritmi classico e quantistico. reticolo MIT
descrizione dell'algoritmo omomorfico
I also want to minimize storage space

Questo è il punto cruciale della teoria della crittografia del disco

    
risposta data 27.08.2011 - 16:55
fonte
1

L'obiettivo principale è che I (come amministratore) non dovrebbe mai essere in grado di leggere i dati di qualcun altro, ma voglio anche minimizzare lo spazio di archiviazione (se possibile).

Un approccio molto diverso per ridurre al minimo lo spazio di archiviazione, senza mai fidarsi completamente dell'amministratore del server di archiviazione remoto, è discusso in " La crittografia convergente è davvero sicura? ".

La crittografia convergente è progettata per consentire al server di archiviazione remoto di deduplicare i file comuni, senza che l'amministratore del server di archiviazione ottenga abbastanza informazioni per decrittografare ciò che si trova in quei file (a parte il fatto che il file A è, in effetti, lo stesso del file B, e quindi deve essere memorizzato solo una volta).

    
risposta data 15.06.2012 - 00:57
fonte

Leggi altre domande sui tag