Cosa devo scambiare con il server quando viene generato il mio codice AES 256?

Question

Cosa devo scambiare con il server quando viene generato il mio codice AES 256?

#1 da (2 voti)

4

Sto creando un gioco dal ritmo frenetico mobile e attualmente sto lavorando all'accesso / registrazione / connessione. Sto cercando di renderlo corretto in modo che non guasteri in futuro.

Per ora, ho letto più articoli su quale metodo dovrei usare per creare una 'sessione utente sicura' tra client e server.

Il mio obiettivo è utilizzare RSA solo per scambiare AES key e inviare pacchetti con AES solo

Dovrebbe apparire così:

Archivia la stessa chiave RSA pubblica su tutti i client

Archivia una chiave RSA privata sul server

Il client invia il ' AES initialization data ' al server crittografato con public RSA . Il server decrittografa AES dati con una chiave privata RSA , memorizza AES dati, crittografa AES dati con AES dati e restituisce al client.

Il cliente riceve AES dati crittografati con lo stesso AES di dati, decodifica e se tutto va bene, l'handshake è fatto, possiamo inviare messaggi in modo sicuro utilizzando AES di dati.

Sto usando Java e ho eseguito l'algoritmo RSA , ho controllato i pacchetti con Wireshark, crittografato e decrittografato e funziona. La cosa che non riesco a completare è la crittografia AES perché mi manca qualche conoscenza.

So che AES usa IV parameter che viene usato come un 'sale' in SHA . Fondamentalmente so come funziona IV, ne leggo alcuni, ma non ho idea di quando e quante volte dovrei inviarlo.

Dovrebbe essere generato IV ancora e ancora con ogni pacchetto o dovrei solo generarne uno con SecretAESKey , salvarlo e usare questa coppia per crittografare i dati e decrittografarli?

Imparo davvero in fretta quindi per favore non giudicarmi perché questa domanda potrebbe sembrarti stupida.

Grazie per l'aiuto!

encryption server client aes rsa

posta Spectre 06.10.2016 - 16:05

fonte

1 risposta

Leggi altre domande sui tag encryption server client aes rsa

Implementazioni del protocollo del segnale: autenticazione e ispezionabilità della chiave di pub? (Allo, WhatsApp, FB messenger, Signal) Integrità delle prove forensi LIVE (ad esempio, dump della memoria)

score 2 · Answer 1

Non farlo mai.

Inventare un protocollo sicuro, anche utilizzando primitive crittografiche di qualità buona, è estremamente difficile. L'implementazione di un protocollo progettato correttamente è ancora considerata difficile, anche quando si utilizzano primitive crittografiche implementate correttamente. Le persone esperte che lavorano su Crypto su Google / Microsoft / Apple hanno commesso errori gravi con questa roba. Hanno imparato da questi errori e tutti ti consigliano di usare l'API più resistente agli abusi che puoi, invece di quello che stai facendo, che utilizza API di livello estremamente basso, in modo grave.

Dalle domande che fai, sei molto lontano dall'essere qualificato per fare questo tipo di lavoro per tutto ciò che lascerà mai il tuo computer.

Sembra che tu stia cercando di inventare la crittografia degli anni '90.

AES non ha un "parametro IV". Stai chiedendo informazioni sui modi operativi a cifrario a blocchi (in particolare CBC, che non è utilizzato in nuovi protocolli), e stai cercando di decidere se effettuare il bug IV deterministico in CBC TLS 1.0. Beh, indovina un po ', il bug è stato inserito nella mailing list nel secolo scorso ed è stato risolto da allora. E poi CBC è stata deprecata a favore delle modalità AEAD, e ora l'industria si trova in modalità AEAD resistenti all'uso improprio che non si rompono in modo catastrofico quando si ripete un nonce. Lavorando da solo senza i migliori crittografi che indicano i problemi con il tuo schema, potresti scoprire tutti quei famosi bug da solo, tra mille anni.

Dato che non hai chiesto come combinare la crittografia e il MAC, sospetto che tu stia facendo una crittografia non autenticata, che è nota per essere catastrofica. Quando scopri che hai bisogno di un MAC, lo combinerai male con la crittografia e il padding, come SSL ha fatto negli anni '90.

Capisci quanto è sicuro il padding di RSA e perché ne hai bisogno?

Stai provando a eseguire lo scambio di chiavi RSA che non è stato consentito in HTTP2 e TLS 1.3, per validi motivi. I protocolli moderni forniscono la segretezza avanzata.

Capisci che il calcolo dell'indice sta lentamente uccidendo RSA e DH classica ed è per questo che le persone sono passate all'ECC?

Per riassumere: non farlo. Mai.

Usa invece libsodium (o tweetnacl). È sicuro, veloce, ha un'API resistente agli abusi, è stato controllato dalle persone migliori. È molto, molto meglio di TLS, anche TLS 1.3 che non è ancora standardizzato.

Per scopi didattici, ti consiglio di fare cryptopals . Imparerai tutto ciò che devi sapere sulla rottura della crittografia.