Quali sono i motivi per l'implementazione di dati crittografati in modo reversibile? [chiuso]

-2

Scusami se sbaglio, dato che sono molto nuovo sul campo, ma sembra che l'unica ragione per cui si debba cifrare qualcosa in modo reversibile è se l'oggetto che riceve i dati crittografati è una persona. (cioè posta criptata, promemoria, parole in codice ecc ...)

Quindi ecco la grande domanda : perché mai qualcuno dovrebbe usare qualcosa di diverso da un hash o altra crittografia non reversibile?

(eccetto dagli esempi sopra)

    
posta Stegosaurus 29.01.2016 - 07:09
fonte

1 risposta

4

In sicurezza, c'è un'idea chiamata "triangolo della CIA", che sta per tre qualità fondamentali della sicurezza: riservatezza, integrità e disponibilità. La crittografia in genere riguarda la riservatezza, mentre l'hashing generalmente riguarda l'integrità.

La crittografia viene utilizzata per garantire la riservatezza delle comunicazioni, ogni volta che la riservatezza è importante. Non importa se si tratta di una persona o di un servizio o di un robot che riceve tali comunicazioni; se devono essere protetti dagli intercettatori, la crittografia può essere uno strumento efficace.

La crittografia viene anche utilizzata per garantire la riservatezza dei dati in futuro. Potrei voler cifrare un file oggi e recuperarlo l'anno prossimo, ma non voglio che altri lo accedano nel frattempo.

La crittografia è recuperabile. Quando è necessario il messaggio originale, il tasto giusto lo rende disponibile. Questo lo rende ideale per le comunicazioni.

(Come bonus, anche la crittografia rende uno strumento efficace per la distruzione istantanea: se hai un disco crittografato, distruggendo tutte le copie esistenti della chiave, tutti i dati sul disco diventano irrecuperabili, indipendentemente dalla quantità di dati disponibile il disco: si tratta di un processo molto più rapido della sovrascrittura e dell'eliminazione di terabyte di dati.)

Un digest di messaggi (hash) viene utilizzato principalmente per garantire l'integrità dei dati, per sapere che non è stato danneggiato durante il trasporto, durante l'archiviazione o modificato da un utente malintenzionato. Fornisce un modo per confrontare due pezzi di dati altrimenti nascosti. Un esempio comune è la dimostrazione che un certificato o un messaggio sono stati firmati con una chiave privata, nota solo al mittente.

I digest di messaggi sono utili per dimostrare la conoscenza dei segreti da utilizzare nelle operazioni di confronto senza esporre direttamente i segreti. L'ovvia implementazione è calcolare il valore hash di una password e memorizzare solo l'hash nel database. La volta successiva che l'utente immette la propria password, si calcola il valore hash e lo si confronta con il valore memorizzato. Questo può dimostrare che l'utente conosceva la password, ma il valore hash non dice a un osservatore quale sia la password. Mantenendo i dati della password originale in uno stato non recuperabile, sembra ben protetto, ma non è sufficiente.

Un digest di messaggi mantiene la proprietà di nascondere il segreto se e solo se i dati segreti originali non sono ipotizzabili. Le password sono brevi e indovinate. I numeri dei conti bancari sono brevi e ipotizzabili. I PIN sono brevi e ipotizzabili. Quindi, per aiutare a proteggere quei tipi di segreti indecifrabili, vengono utilizzate misure aggiuntive, come l'aggiunta di sale casuale, limitando l'accesso al sistema di confronto (cioè inserisci 3 password errate di fila e sei bloccato) e applicando ricorsivamente l'algoritmo di hash migliaia di volte prima di memorizzare il valore hash.

Se il segreto è intuibile e l'attaccante conosce il valore dell'hashed, l'attaccante può semplicemente provare milioni o miliardi di valori probabili come input per la routine dell'hash e se il suo output corrisponde sempre all'hash memorizzato, sa che il suo input sarà funziona come una password valida. Inoltre, se un utente malintenzionato può semplicemente rubare una copia dell'hash e presentarla come se fosse stata inserita dall'utente, il confronto passerà comunque, eliminando la necessità di recuperare la password originale. La distribuzione di software in questi scenari richiede conoscenza e attenzione per evitare questi (e altri) errori comuni.

    
risposta data 29.01.2016 - 08:30
fonte

Leggi altre domande sui tag