La crittografia due volte con due chiavi in sequenze diverse porta allo stesso risultato?

È possibile utilizzare qualsiasi crittografia simmetrica che funzioni generando un flusso di byte dipendente dalla chiave, che viene quindi sottoposto a XOR con i dati da crittografare. Questo è il caso della maggior parte dei codici a flusso ; questo vale anche per un codice a blocchi in modalità CTR (che praticamente trasforma un codice a blocchi in un flusso cifra).

Tali cifrari sono un po 'delicati da usare, perché non dovrai mai riutilizzare un determinato flusso dipendente dalla chiave (sarebbe il famigerato "doppio pad"). Ciò significa che verrà utilizzata una determinata chiave per crittografare solo il messaggio one o che utilizzi un codice di flusso con un vettore di inizializzazione che necessiterà di una propria gestione. Fondamentalmente , nel tuo caso, questo significa che ai potenziali attaccanti non dovrebbe essere permesso di osservare E (k1, t) , E (k2, t) e E (k1, E (k2, t)) , perché ciò consentirebbe loro di recuperare t (cioè da XOR tutti e tre i flussi insieme).

Se il tuo scenario specifico rende inapplicabile la soluzione di cifratura del flusso, allora dovresti usare più soluzioni esoteriche che non sono standard, quindi non possono essere raccomandate nella pratica (ma vanno bene per la ricerca). Ad esempio, dati Parametri del gruppo Diffie-Hellman (un modulo p e un generatore g che è tale che g ^q = 1 mod p per un primo q che divide p-1 ), un elemento di sottogruppo (un g ^x per alcuni interi x ) può essere "criptato" con la chiave a aumentandola alla potenza a ( E (a, h) = h ^a mod p ). "Decryption" implica il sollevamento per alimentare 1 / a mod q (modulo inverso q è calcolato con algoritmo euclideo esteso ). Con questo algoritmo di "crittografia", ottieni la commutatività che cerchi ( E (a, E (b, h)) = E (b, E (a, h)) ) E puoi pubblicare E (a, h) , E (b, h) e E (a, E (b, h)) senza rivelare h .

... ma questa è solo una variante di Diffie-Hellman. La buona domanda è quindi: perché vuoi la tua cosa di crittografia commutativa? Che cosa stai cercando di fare, che Diffie-Hellman non può fare?

RSA (non imbottigliato) segue questo requisito, se usi due coppie di chiavi diverse ma lo stesso modulo: ( Aggiornamento: no non lo fa, come ha sottolineato Thomas Pornin nei commenti)

(t^k1)^k2 = t^(k1*k2) = (t^k2)^k1

Se hai bisogno di un codice simmetrico, funziona anche un semplice One-Time-Pad (anche se in questo caso, la lunghezza della chiave deve essere grande almeno quanto il messaggio e non dovrebbe mai essere riutilizzata):

(t xor k1) xor k2 = (t xor k2) xor k1

Potrebbero essercene anche altri. Ti suggerisco di consultare gli algoritmi crittografia omomorfica per ulteriori informazioni, anche se non sono sicuro che siano commutativi nel modo desiderato a (e probabilmente non così strong come quelli che non hanno questa restrizione).

Aggiornamento: alcune note in base al tuo feedback:

• Poiché le chiavi non dovranno mai essere scambiate (ovvero la parte che crittografa è l'unica che conosce la chiave), la lunghezza della chiave OTP non è davvero un problema;
• Se il canale utilizzato dalle parti per comunicare tra loro è sicuro, non è necessario proteggere i dati da un utente malintenzionato di terze parti;

• Se esegui un'operazione di crittografia ma non rivela mai il risultato , non importa se riutilizzi o meno la tua chiave. Ecco la mia comprensione del protocollo (disclaimer: non sono un crittografo, ho una conoscenza molto limitata dell'argomento e può essere totalmente sbagliato, il mio consiglio sarebbe, se possibile, seguire un protocollo stabilito, come Yao's Millionaires 'problem ):

  Alice                    Bob
  a1, k1, a1 xor k1        a2, k2, a2 xor k2
  a2 xor k2          <==>  a1 xor k1
  a2 xor k2 xor k1         a1 xor k1 xor k2
  

  Se a1 == a2 , i risultati di Alice e Bob saranno uguali. Il problema ora è: come confrontarli? Alice ha riutilizzato k1 , quindi non può inviare a2 xor k2 xor k1 a Bob o sarebbe in grado di recuperare k1 (eseguendo xo con a2 xor k2 ).

  Ma supponendo che k1 sia abbastanza grande, può inviare un hash del risultato, in modo che Bob possa confrontare il suo hash del suo risultato. Finché Bob non può invertire l'hash, non impara nulla su k1 . Se k1 è stato generato da un CSPRNG, anche un hash veloce come SHA-512 dovrebbe essere abbastanza sicuro.

  (Nota: Bob avrebbe anche bisogno di inviare ad Alice il suo hash per il confronto, mentre questo protocollo non garantisce alcuna informazione su a1 o a2 diverso dal fatto che siano o meno uguali, nulla impedisce a nessuno di a cheat - entrambi possono inviare un hash non correlato per convincere l'altro che i valori sono diversi, oppure il primo ricevitore può re-inviare lo stesso hash per convincere il primo mittente che i valori sono uguali)

Sono sorpreso che nessuno abbia menzionato Zero Knowledge Proofs ancora. Sembra la definizione di ciò che stai cercando.

Inoltre, è necessario che il sistema sia reversibile? Se sta semplicemente dimostrando di conoscere un determinato valore, prendere la HMAC della combinazione attributo / valore può dimostrare che tu conoscere il valore senza dire quale sia il valore (presupponendo che l'altro lato abbia gli stessi valori per poter verificare l'HMAC).