Questo algoritmo è davvero end-to-end crittografato e sicuro?

1

Sto creando una chat anonima in cui una delle premesse è che le conversazioni sono end-to-end crittografate. Sto utilizzando Firebase in modo che tutta la comunicazione tra i client e il server sia protetta SSL. Ma sto cercando di nascondere la chat anche dal server.

Ho avuto la seguente idea per lo scambio di chiavi. Tieni presente che non sono disposto a utilizzare Diffie Hellman poiché non sono riuscito a trovare le librerie JavaScript supportate, pertanto eseguiremo solo RSA e qualsiasi altra crittografia simmetrica.

Ecco l'algoritmo:

  • L'utente Alice desidera chattare con Bob .
  • Alice genera una coppia di chiavi pubblica / privata e invia la sua chiave pubblica a Bob .
  • Bob accetta la chat generando una chiave pubblica / privata e invia la parte pubblica a Alice .
  • Ora il server e gli utenti conoscono entrambe le chiavi pubbliche.
  • Alice , chi è l'utente che ha avviato la chat, genera una chiave simmetrica, crittografala con la chiave pubblica Bob .
  • Poiché qualsiasi altro utente può crittografare questa chiave e inviarla con bob, Alice invia anche l'hash del messaggio crittografato crittografato con la sua chiave privata, quindi Bob può verificarlo era Alice che ha generato la chiave.
  • Alice invia il messaggio (chiave simmetrica crittografata + firma digitale) a Bob .
  • Innanzitutto, Bob decrittografare la firma digitale con la chiave pubblica Alice e confrontarla con il messaggio crittografato, se non controllano, la chat fallisce.
  • Bob decrittografa la chiave simmetrica con la sua chiave privata.
  • Ora Bob e Alice hanno la stessa chiave simmetrica e Bob è sicuro che sia stato Alice a generare questa chiave.

Questo algoritmo è corretto?

    
posta rafael 08.05.2016 - 23:56
fonte

1 risposta

4

Non c'è autenticazione in ciò che hai documentato. Alice non può sapere se lo scambio di chiavi avviene con Bob, il tuo server sta agendo in modo pericoloso o con altri MiTM. Quindi passi come:

Alice generates a public/private key pair and send its public key to Bob.

sono descritti più accuratamente come "Alice invia la sua chiave pubblica a qualcuno, sperando che sia effettivamente Bob."

Questo è il motivo per cui SSL utilizza certificati e autorità di certificazione. Consentono l'autenticazione senza comunicazione precedente. È inoltre possibile supportare la trasmissione fuori banda delle informazioni di autenticazione. SSH si basa su questo (spesso finisce per essere il primo messaggio di fiducia e autenticare quelli successivi). Generalmente, per stabilire la sicurezza è necessaria una comunicazione fuori banda (ad es. Passare i codici a barre tra i dispositivi) o fidarsi del fatto che il server non sia malizioso. Non sembri disposto a fidarti del server, quindi avrai alcuni problemi senza uno scambio di chiavi fuori banda.

Ci sono anche molti attacchi ai canali laterali che potrebbero diventare applicabili. Ad esempio, la gestione degli errori può talvolta essere utilizzata come un attacco oracle .

    
risposta data 09.05.2016 - 04:07
fonte

Leggi altre domande sui tag