Autenticazione sicura incondizionata

-1

Sto cercando di aggiungere l'autenticazione per la mia implementazione One-Time Pad.
So che per fornire l'autenticazione incondizionatamente protetta ho bisogno di utilizzare l' autenticazione MAC One-Time .

Ma non capisco perché una soluzione come la seguente (che è molto più facile da implementare) non fornisce lo stesso livello di sicurezza: /

ciphertext = ((plaintext || H(plaintext)) XOR OTPKey)

With:
|| = concatenation
H = SHA-2
OTPKey is long enough to encrypt the plaintext and H(plaintext)

Mallory qui non può forzare il testo cifrato (a causa del pad singolo), quindi non può ottenere il testo normale corretto né il digest ...

È giusto? Questo può fornire un'autenticazione incondizionatamente sicura?

So che in pratica è vulnerabile a noto -plaintext attacks quindi, per favore, non considerarlo in questo caso particolare. Sono interessato alla sicurezza incondizionata, nel senso che sia il testo in chiaro che il sommario possono beneficiare della sicurezza basata sulle informazioni fornita da One-Time Pad.
Sono interessato agli attacchi passivi e non a quelli attivi.
Supponiamo che Mallory qui conosca solo il testo cifrato; -)

In altre parole: posso essere sicuro che un utente malintenzionato non possa ottenere il testo in chiaro sfruttando le possibili vulnerabilità introdotte dall'uso di una funzione di hash per il calcolo del digest?

Variante
Che ne dici di questa variante? Posso dire che fornisce la sicurezza della teoria dell'informazione per il testo in chiaro E è vulnerabile contro attacchi attivi con complessità di 2 ^ 256?
Quindi in questo caso posso fornire un certo livello di sicurezza anche contro gli attacchi in chiaro (anche se la sicurezza computazionale).

ciphertext = (plaintext XOR OTPKey)
message = (ciphertext || H(ciphertext || K2))

With:
K2 = 32 bytes of random key, NOT correlated with OTPKey

Grazie a tutti:)

    
posta Riccardo Leschiutta 05.12.2015 - 20:22
fonte

1 risposta

1

can I be sure that an attacker can't obtain the plaintext exploiting possible vulnerabilities introduced by the use of a hash function for the digest calculation?

Penso che tu sia al sicuro. Penso che l'unico problema potrebbe essere con l'implementazione OTPKey. Non è possibile riutilizzare la stessa chiave due volte, deve essere veramente casuale e la chiave stessa deve essere sicura e nota a entrambe le parti. Inoltre, il contenuto del messaggio deve essere completamente imprevedibile, altrimenti la chiave sarà teoricamente vulnerabile ai metodi di attacco a forza bruta. Per questo motivo, implementerei anche un valore casuale all'inizio del messaggio in XORd con il resto del messaggio prima di qualsiasi cosa. A parte questo, dico che tutti i motori vanno.

Aggiorna

Per quanto riguarda questo metodo:

ciphertext = (plaintext XOR OTPKey)
message = (ciphertext || H(ciphertext || K2))

With:
K2 = 32 bytes of random key, NOT correlated with OTPKey

Questo dovrebbe essere efficace fintanto che l'attaccante non riesce ad afferrare K2

    
risposta data 05.12.2015 - 21:57
fonte

Leggi altre domande sui tag