Si tratta di un hash sicuro "Funzione" per l'integrità?

0

Mi chiedevo quali fossero i problemi di sicurezza (non efficieny) possibili con questa "funzione" di hash:

Sebbene non sia una funzione reale, questo metodo trasforma un messaggio di qualsiasi lunghezza in un messaggio di lunghezza fissa. Dove non è possibile ricavare il messaggio dal messaggio di lunghezza fissa hash.

-Alice vuole inviare un messaggio (m) a Bob.

-Alice e Bob usano un cifrario simmetrico con una chiave condivisa in un altro modo.

-Alice quindi genera due numeri veramente casuali della stessa lunghezza del messaggio (m) ed esegue un OTP sul messaggio due volte, un tasto applicato a me un tasto applicato al risultato dell'altro tasto e m .. Alice distrugge le chiavi.

-C'è un server chiamato "server hash" che è un membro di terze parti fidato da Alice e Bob e da tutti gli altri mittenti.

-Alice invia il doppio testo cifrato OTP al server.

-Il server risponde quindi con un messaggio a lunghezza fissa più breve del testo cifrato e lo chiama hash di (m) che il server non conosce. Questo messaggio a lunghezza fissa è un numero veramente casuale che viene memorizzato sul server e inviato ad Alice.

-Alice concatena il doppio OTP crittografato con me usa il codice simmetrico per crittografarlo.

-Alice invia il (MAC) insieme al testo cifrato

-Bob invia il doppio testo cifrato al server. Il server controlla se questo corrisponde a qualcosa nel suo database e invia l'hash risultante a Bob. Se il risultato corrisponde a MAC di Alice, il messaggio è intatto.

Non ci sono collisioni poiché il server non invierà mai lo stesso numero casuale per due diversi messaggi. La doppia crittografia è tale che Bob non può derivare la chiave OTP di Alice dal messaggio che ha ricevuto da lei.

    
posta dylan7 01.07.2015 - 01:06
fonte

1 risposta

5

Sono un po 'confuso su quello che stai cercando di ottenere con questo protocollo piuttosto complicato e soggetto a errori.

Se comprendo correttamente la tua idea, stai semplicemente spostando il problema dell'integrità nelle comunicazioni con il "server hash". Se qualcuno fosse in grado di MITM sia del traffico in entrata che di quello di Alice e Bob, potrebbe confondere il messaggio di Alice, quindi fare in modo che il server invii un "hash" arbitrario ad Alice quando ne richiede uno e restituisce lo stesso valore a Bob quando chiede un "hash" la prossima volta.

Ci sono anche altre ipotesi che sembrano contraddittorie per me; Ad esempio, è matematicamente impossibile per il server "non inviare mai lo stesso numero casuale per due messaggi diversi" se si richiede anche che ogni hash sia un "messaggio di lunghezza fissa più corto di il testo cifrato". Inoltre, non vedo alcuna ragione per cui a Bob non dovrebbe essere permesso di "derivare la chiave OTP di Alice" - cosa farebbe comunque con esso? Pertanto, la crittografia "double OTP" non mi sembra necessaria.

Probabilmente l'hai già sentito prima, ma c'è questa regola nella crittografia che dice "non eseguire il rollover", che in pratica significa che non dovresti provare a inventare il tuo protocollo se ci sono soluzioni stabilite che non sono state rotto finora. Il motivo è che questi protocolli ben consolidati hanno di solito subito molte ricerche da un gran numero di persone molto intelligenti, a differenza del tuo "nuovo" algoritmo che hai inserito nei forum di stackexchange per la discussione;)

    
risposta data 01.07.2015 - 03:03
fonte

Leggi altre domande sui tag