Devo crittografare i file salvati dal mio programma

Direi di no, non dovresti codificarli per più motivi

• Averli più aperti è meno lavoro per te. La tua azienda ha bisogno di spendere il lavoro extra per nasconderlo?
• Avere crittografato crea il lock-in. Il lock-in non è una funzione di vendita
• Se la tua app lo decifra, significa che la crittografia può essere violata esaminando la tua app, quindi hai appena fatto del lavoro con scarso guadagno: non appena una persona lo interrompe, chiunque può ripeterlo.
• Avendolo aperto consente ai tuoi utenti di fare cose con i dati che non hai previsto e non hanno aggiunto alla tua app - questo significa che hai dato loro un'ulteriore utilità.
• L'apertura dei dati renderà le future partnership più semplici perché un partner non avrà bisogno di scrivere la logica di consegna.
• L'apertura dei dati non significa che gli strumenti della concorrenza che utilizzano tali dati appariranno magicamente - i concorrenti devono ancora scrivere il proprio software, il che probabilmente non è una buona idea come solo usare il tuo - quanto sforzo vorrà qualcuno a voler solo NON usare il tuo software?

Questo non è affatto un elenco completo, solo quello che mi viene in mente.

Un fatto davvero importante che le persone trascurano sempre della crittografia è che non fa assolutamente nulla per garantire l'integrità dei dati. La crittografia risolve il problema della riservatezza; impedisce agli utenti non autorizzati di leggere i dati. La crittografia renderà più difficile per qualcuno modificare i dati in modo utile, ma non risolve il problema giusto.

Se sei preoccupato per altri programmi che modificano i tuoi dati, ciò di cui hai effettivamente bisogno è un'impronta digitale affidabile dei tuoi dati. Un modo comune per farlo è generare un hash del database quando il programma lo modifica e quindi firmare l'hash con una chiave privata. Quando carichi il database, calcola l'hash, confrontalo con l'hash firmato e verifica che la firma sia valida.

Ora che la questione della teoria è fuori mano, vale la pena notare che, in pratica, la crittografia dei dati potrebbe essere abbastanza buona per questo genere di cose. Eventuali modifiche cieche ai dati strutturati crittografati probabilmente corromperanno il database, in modo tale da impedire agli utenti di modificare il database utilizzando qualsiasi cosa diversa dall'applicazione. Se vuoi anche assicurarti che nessun altro possa leggere i tuoi dati (non era chiaro nella domanda), probabilmente sei sicuro di lasciarlo alla crittografia e farlo con esso.

Vuoi limitare la manomissione o limitare la visualizzazione dei dati? La soluzione potenziale per ciascuno richiederebbe implementazioni leggermente diverse.

Manomandando userai gli hash. Come esempio reale, un'applicazione su cui lavoravo calcolava gli hash di stringhe e / o file. Quando gli utenti hanno scaricato il file, abbiamo controllato l'hash. Quando l'utente ha aperto il file, abbiamo controllato l'hash. Questo perché il nostro cliente non voleva che gli utenti si intromettessero con i file (jpg, ecc.) Ciò impediva agli utenti di manomettere il file, perché se lo facevano, gli hash non corrispondevano e ottenevano un errore. Qualsiasi file / stringa può essere sottoposto a hash e, se non si desidera che l'utente manchi le stringhe oi file senza problemi, memorizza un hash di tali dati insieme alla stringa / al file. Le password non devono essere crittografate, la soluzione sarebbe quella di salare la password e poi cancellarla. Quindi l'archivio dati e l'applicazione non sono a conoscenza delle password utente.

La crittografia verrebbe utilizzata per nascondere informazioni quali carta di credito e / o dati personali. I requisiti legali e normativi dovrebbero definire ciò che deve essere crittografato. Se l'applicazione sta memorizzando dati sensibili, quindi uno dei modi per impedire l'accesso è tramite crittografia. Puoi anche limitare l'accesso definendo ACL ecc. Ma se vuoi solo i tuoi utenti per visualizzare i dati, allora la crittografia è l'opzione migliore.

Inoltre, implementalo solo se necessario. Tornando all'esempio sopra, in origine abbiamo avuto una resistenza alla manomissione nell'applicazione. Gli utenti hanno scaricato i file e sono stati aperti e visualizzati localmente. Solo dopo aver chiesto a un cliente che gli utenti non potessero manomettere i file, abbiamo implementato un controllo di hashing. Durante la progettazione abbiamo preso in considerazione due opzioni, limitando l'accesso al file system ai file scaricati o utilizzando un hash. Scegliamo un hash perché lo stavamo già calcolando sul caricamento, quindi è stato relativamente semplice aggiungere un controllo prima che l'utente potesse vederlo.

Se tutto ciò che stai cercando è di scoraggiare l'editing esterno, pur garantendo l'interoperabilità tra i diversi linguaggi di implementazione, considera semplicemente la compressione del file. Sembrerà rumore di linea se aperto in un editor di testo, ma se si utilizza un algoritmo di compressione standard si dovrebbe essere in grado di trovare (o scrivere) una libreria di compressione dei file per le lingue più diffuse. Hai anche il vantaggio di risparmiare spazio di archiviazione, se i tuoi set di dati diventano grandi.

Come ho capito la tua domanda, non ti importa se qualcuno modifica o guarda il tuo database, è solo che preferiresti che non lo facessero.

Daenyth è un buon argomento per cui non dovresti farlo, ma se decidi di andare comunque, prendi in considerazione alcune cose:

• Crypto è difficile da correggere

Anche se crittografate i vostri dati con AES o che cosa avete, il valore dei dati non richiede realmente la crittografia / protezione. Potrebbe anche rendere più difficile leggere i dati in futuro in una lingua diversa o persino con una libreria diversa.

• Stai meglio con l'offuscamento

che significa che farà un Base64 semplice. Ovviamente questo non farà nulla per verificare l'integrità dei dati come indicato da Dan ma l'implementazione delle firme è ancora troppo costosa. In alternativa, è possibile aggiungere padding al file per conformarsi a una serie di checksum fissi (per alcune funzioni di checksum). Molto più leggero delle firme ma ancora piuttosto costoso.

Se in futuro è necessario disporre di una connessione affidabile a un database remoto, richiedi di nuovo quando lo implementa.

Come per SQLite vs XML c'è una domanda su StackOverflow sullo stesso argomento. Sebbene chiuso, ha alcune risposte eccellenti.

Modifica: se stai usando Java potresti prendere in considerazione la possibilità di zippare il file. Si ottiene sia un blob binario illeggibile che un checksum . Sono sicuro che C # ha anche una versione di questo, ma non ho familiarità con quella lingua.