Decrittografia parziale mediante servizio di decrittografia non attendibile

Question

Decrittografia parziale mediante servizio di decrittografia non attendibile

#1 da (1 voti)

1

Sebbene esistano modi per crittografare e decrittografare le informazioni, la maggior parte di queste sembra piuttosto pesante da calcolo. Per questo motivo sto pensando di suddividere la decrittografia in due parti: una è pesantemente calcolata e l'altra è una luce computazionale. La prima parte viene eseguita sul server remoto non attendibile utilizzando un qualche tipo di chiave di sessione, mentre la seconda parte viene eseguita sul lato client conoscendo la chiave effettiva.

L'utente ha una chiave K e sul server sono presenti informazioni crittografate T. L'utente genera un po 'di K1 dalla sua K e lo invia al server. Il server tenta di decrittografare T con K1 e ottiene invece un T1. Non è ancora completamente decrittografato e nessuno dei T, T1, K1 consente al server di calcolare K. Tuttavia K1 viene generato in un modo in cui l'utente può facilmente decifrare T1.

Questo approccio è possibile? Quali potrebbero essere potenziali problemi?

Aggiornamento: ho trovato un esempio di come potrebbe essere fatto: l'utente genera più chiavi - K1, K2, K3 ... KN, le mescola e aggiunge la propria chiave K nel miscuglio. Quindi invia tutte quelle chiavi al server e chiede di decrittografare T con ciascuna di queste chiavi. Il server non sa quale chiave è quella corretta, mentre l'utente sa quale di T1 .. TN è l'effettiva informazione decrittografata mentre il resto è spazzatura. Questo particolare approccio presenta molti punti deboli intrinseci, oltre a non consentire l'utilizzo del server per la crittografia (ovvero è "di sola lettura"), ma è un po 'quello che sto cercando.

Aggiornamento 2: (Dato che ho speso la mia reputazione in merito, non posso più commentare le risposte). L'idea è di avere una funzione che può essere applicata a una chiave e la sua funzione inversa che potrebbe essere applicata a un "testo semplice" che è facile da calcolare e che non può essere previsto dal server (cioè non costante di sicuro). "Genera garbage" e "discard garbage" sono esempi di questo. Il "generare hash da chiave" e "non fare nulla" non sono abbastanza buoni - il server può semplicemente omettere la crittografia, quindi funziona solo se l'hash è diverso per ogni sessione.

Non so se è possibile, ma non posso nemmeno dimostrarlo impossibile.

cryptography encryption decryption

posta aragaer 07.06.2016 - 13:54

fonte

1 risposta

Leggi altre domande sui tag cryptography encryption decryption

È sicuro utilizzare OAuth (concessione delle credenziali della password del proprietario della risorsa) per l'autenticazione? Domande sul server remoto

score 1 · Answer 1

La tua premessa non è corretta, ma concettualmente penso che il problema a cui stai alludendo sia stato risolto da gestori di password basati su server che utilizzano funzioni di derivazione della chiave basate su password (ad esempio PBKDF2).

Il motivo per cui la tua premessa non è corretta è che la crittografia e la decodifica simmetriche (ad esempio AES) sono veloci anche in JavaScript. In questi giorni il costo è basso soprattutto quando molti dispositivi consumer hanno hardware dedicato per elaborarlo.

La crittografia asimmetrica (basata su chiavi pubbliche e private) d'altra parte è costosa e, se l'elaborazione diventa proibitiva in un'applicazione, è probabile che venga applicata in modo errato.

Anche se con un algoritmo come la crittografia e la decrittografia AES è veloce, se non si conosce la chiave corretta ci vorrà un'eternità per indovinare quella giusta perché ci sono troppe cose da indovinare (specialmente con 256 bit). Ciò è ulteriormente aggravato dall'uso di PBKDF2, che spiegherò tra poco.

Sebbene tu dica che il server non è affidabile, ti fidi abbastanza per ricevere e archiviare i tuoi dati crittografati, ma presumo che non ti fidi di ricevere e archiviare direttamente qualsiasi tipo di dati riservati in testo semplice. Un'altra ipotesi che farò è che il server proverà a garantire che i dati crittografati vengano inviati solo a te, e non a tutti quelli che semplicemente lo chiedono. Supponendo che sia ragionevole, presenterò uno schema utilizzando PBKDF2 che molti servizi di gestione password basati su server utilizzano.

Che cos'è PBKDF2? Crea una chiave da un'altra chiave, proprio come la tua K a K1. La cosa interessante di PBKDF2 è che può essere veloce o lento quanto vuoi: più grande è il numero di iterazioni più lento è.

Registrazione con il server per stabilire le credenziali di autenticazione e inviare dati crittografati:

//// JavaScript client side
PBKDF2(password, 1000 rounds) => encryption key // fast because low number of rounds
encrypt(encryption key, data) => encrypted data // fast even with AES 256
hash(encryption key) => auth key

// send encrypted data and auth key to server

//// Server side
PBKDF2(auth key, 100000) => server hash // slow because high number of rounds
// store server hash and encrypted data

Quando successivamente accedi al server:

//// JavaScript client side
PBKDF2(password, 1000 rounds) => encryption key // fast because low number of rounds
hash(encryption key) => auth key

// send auth key to server

//// Server side
// verify auth key
PBKDF2(auth key, 100000) => server hash // slow because high number of rounds

// if server hash matches what was previously stored return encrypted data
// send encrypted data back to client

//// JavaScript client side
decrypt(encryption key, encrypted data) => data // fast

Nota che il mio riferimento a PBKDF2 sopra è una semplificazione per dimostrare il suo ruolo piuttosto che l'uso effettivo.

Credo che questa proposta risolva il problema intrinseco che penso tu stia chiedendo, senza bisogno di un nuovo tipo di crittografia, e invece di fare affidamento su tecniche crittografiche forti note. Tutto sul lato JavaScript del client è piuttosto veloce poiché si conosce la password / chiave, mentre cercare di ottenere i dati crittografati, quindi rompere la crittografia dal lato server è costoso.

Punti salienti della proposta:

Tutto sul lato client è veloce.
- PBKDF2 ha un basso numero di round quindi è veloce
- La crittografia e la decrittografia AES sono veloci
non è mai al corrente di:
- Password testo normale
- Dati riservati (decrittografati)
Il server memorizza i dati crittografati. Per ottenere qualsiasi informazione da qui è costoso.
- L'autenticazione richiesta per ottenere i dati crittografati è relativamente lenta. Prima linea di difesa.
- Se un'entità malintenzionata riesce in qualche modo a ottenere i dati crittografati, per decrittografarli impiegherà ancora molto tempo perché non conoscono la chiave di crittografia. Seconda linea di difesa.