Suppongo che tu stia realizzando un protocollo giocattolo per il gusto di farlo - scopri la crittografia, divertiti a implementare qualcosa, ma comprendi che questo schema giocattolo è probabilmente imperfetto e che se hai dati sensibili dovresti usare ben noto protocolli controllati, non schemi giocattolo che ti sono venuti in mente. (Se non vedi i motivi non rollare il tuo ).
Innanzitutto, RSA descrive solo lo schema c = m^e mod N in cui crittografate un messaggio m con una chiave pubblica (N,e) e decifrate con la coppia di chiavi private (N,d) tramite m = c^d mod N . Non dovresti crittografare il tuo OTP con RSA - sarà molto inefficiente e ci sono molti attacchi contro RSA senza una corretta spaziatura. Dovresti davvero usare sempre schemi di padding come OAEP (in particolare PKCS # 1v2 ). RSA è costoso per i messaggi lunghi, in pratica si utilizza sempre la crittografia ibrida. Questo è usare RSA per crittografare una chiave generata a caso per una funzione di crittografia simmetrica come AES (le altre funzioni di crittografia vanno bene, basta scegliere AES per concretezza). Quindi Alice invia prima E RSA (RSA-PubKey, OAEP (chiave casuale AES)), dove RSA-PubKey = (N, e) ed E RSA (RSA -PubKey, m) = m e mod N. Quindi invia i dati segreti crittografati AES E AES (Random-AES-Key, Secret-Data), che solo significa che Secret-Data è crittografato con AES e la Random-AES-Key generata di recente. Quindi il ricevitore prima decrittografa la chiave AES usando RSA con la chiave privata (N, d) e quindi annulla il padding OAEP, quindi decrittografa il messaggio usando quel tasto AES per recuperare i dati segreti.
Detto questo, checksum non dovrebbe essere usato per impedire la manomissione di un messaggio in transito. Se un utente malintenzionato può indovinare un messaggio, può calcolare il checksum e quindi manomettere il messaggio crittografato per modificare sia il messaggio che il checksum. Ad esempio, se il messaggio è stato crittografato con la modalità AES-CTR e il messaggio è m = "Transfer $1000 from Alice to Bob's account." e utilizza l'hash MD5 come checksum h=b2a26c14a029b0a2aadba4fa2ecd32d2 . Eve potrebbe calcolare xor tra quel messaggio e m' = "Transfer $9999 from Alice to Eve's account." che ha il checksum md5 h' =308b23cb47b0efff365c2593e0a005d7 e quindi XOR il messaggio crittografato con m XOR m' e il checksum crittografato con h XOR h' .
I codici di autenticazione dei messaggi sono il modo per garantire l'integrità del fatto che il tuo messaggio non sia stato manomesso. Questi sono essenzialmente checksum che si basano intrinsecamente su una chiave segreta condivisa. C'è sempre una domanda su come MAC, in caso di Encrypt-then-MAC - (invio E(Data) ++ MAC(E(Data) ) o MAC-then-Encrypt (invio E(data ++ MAC(data)) ) o Encrypt-and-MAC (invio E(data) ++ MAC(Data) ), ma Encrypt-then-MAC è l'opzione migliore per il consenso sebbene altri schemi possano essere sicuri per determinati codici .
Ci sono altri problemi (ad es. la generazione di OTP è piuttosto costosa e utilizza molta entropia che potrebbe essere problematica). Inoltre, non vedo cosa guadagna il passaggio OTP in sicurezza, ad esempio, se il passaggio RSA viene compromesso, tutti gli altri dati vengono compromessi anche da eventuali utenti non autorizzati.
Inoltre, il pad unico ha una sicurezza dimostrabile quando il pad viene utilizzato esattamente una volta. Il pad a molti tempi è notoriamente debole come c1 XOR c2 = m1 XOR m2. Ad esempio, supponiamo che Eve non possa inviare richieste di file a Bob, che esista una funzione di autenticazione non rivelata che verifica l'identità di Alice a Bob prima che Bob risponda indietro con un file crittografato tramite un OTP). Se osserva Alice chiedere file1, inviando un OTP crittografato da 7 MB (OTP1), potrebbe quindi richiedere file2 (solo 6 MB) per inviare gli stessi primi 6 MB di OTP1. Bob risponde quindi con file2 XOR OTP1, passando a Eve lo XOR di file1 e file2. Quindi insieme all'OTP che è MAC'd, ci deve essere uno schema con un nonce casuale (generato dal server) che deve essere incluso con l'OTP crittografato, che viene verificato (per assicurarsi che il pad crittografato non sia stato sostituito con un OTP precedentemente utilizzato).