Quello che stai descrivendo è la versione perpetua del movimento di un pad singolo. Non funziona; lo spazio che devi condividere con il prossimo pad si accorcia con ogni messaggio. Qualsiasi dato bit in un pad singolo può essere utilizzato solo per crittografare un bit del messaggio.
Diciamo che hai dato un pad da 100 KB ("chiave") ad Alice. Quindi le mandi un file da 50 KB; questo prende 50KB del tuo pad. Puoi, se vuoi, utilizzare gli ultimi 50 KB per inviare un nuovo pad. *
Alice ora ha solo 50 KB di pad che non sono mai stati utilizzati (i 50 KB che sono stati inviati con la crittografia del pad originale, seguendo il file). Vuole inviarti un messaggio da 30KB, quindi lo cripta con il pad non usato e poi usa il resto del pad - un altro valore di 20KB - per inviarti un nuovo pad casuale. Il resto del messaggio viene riempito con byte casuali per avere la stessa lunghezza del primo messaggio.
Se Alice provasse a usare quei 50KB per qualcosa di reale (come più materiale chiave), avrebbe dovuto riutilizzare parte di un pad che era già stato usato, violando la natura "una tantum" del pad e spostandolo da "teoricamente indistruttibile" a "lavoro di laurea a casa nella prima settimana della lezione" (supponendo che il nuovo materiale chiave sia mai stato usato da solo come un pad "una tantum").
Ora hai solo 20KB di pad che non sono mai stati utilizzati. Questo è dopo aver scambiato 80 KB di messaggi effettivi. Non è una coincidenza che questi numeri riassumano i 100KB di pad originali scambiati inizialmente. Non puoi aggiungere entropia aggiuntiva (casualità / numeri imprevedibili) nel sistema eccetto scambiando ulteriori chiavi.
* Come forse avrai notato, non c'è motivo di masterizzare 50KB, 20KB, o qualsiasi altra cosa del one-time pad che invii un nuovo one-time pad. La quantità di nuovo materiale chiave trasmessa è uguale alla quantità di vecchio materiale chiave reso inutile. Puoi anche non usare la parte rimanente del pad originale fino a quando non ne hai bisogno per il contenuto effettivo del messaggio.
I moderni algoritmi di crittografia, che sono molto più complicati di XOR (sebbene possano usare XOR come parte dello schema crittografico completo), hanno modi per "allungare" una chiave in modo da poter crittografare i dati più a lungo di se stessa, senza esporre la chiave (anche indirettamente) il modo in cui XOR lo fa. Questo è, ad esempio, il modo in cui funzionano tutti i codici di flusso; prendono una chiave e da quella chiave possono produrre un flusso quasi infinito di valori pseudo-casuali (cioè sembrano casuali se non si sa da dove vengono generati) che possono essere usati per la crittografia e decrittazione (tramite XOR). Il fatto che non puoi mai riutilizzare alcuna parte di quel flusso non è un grosso problema; è possibile renderlo super lungo, e puoi potenzialmente inviare un'altra chiave - che sarà estesa a un lungo flusso - se ti avvicini alla fine. La sicurezza totale di questo schema è solo (nella migliore delle ipotesi) buono come la chiave originale - se la chiave originale era lunga solo 40 bit, ad esempio, ci vorrà solo un po 'più di un trilioni tenta di capire come decifrare l'intero messaggio inclusa la chiave usata per il prossimo bit, ma con chiavi sufficientemente lunghe (128+ bit) che sono generalmente accettabili.
Vale la pena notare che anche i codici moderni non sono necessariamente così forti come implica la lunghezza della chiave. Ad esempio, il codice di flusso RC4 (che utilizza chiavi a 128 bit) è stato recentemente trovato irrintracciabile (almeno per la parte iniziale del messaggio) se è possibile catturare alcuni milioni o miliardi di byte di messaggi (più alcune ipotesi- e-controlla, con più indovinelli necessari per meno dati catturati). Ciò è dovuto al fatto che il "keystream" - i dati pseudo-casuali di una volta sola generati generati da una determinata chiave - è risultato essere in realtà non abbastanza casuale; ha bias (un dato bit non ha ugualmente probabilità di essere zero o uno) che potrebbe essere scoperto esaminando abbastanza testo crittografato in cui è noto il testo in chiaro corrispondente, e usando la conoscenza di tali pregiudizi per rompere la crittografia su testo cifrato il cui testo in chiaro è < em> not conosciuto.