Secret Santa - implementazione che non richiede che un partecipante si fidi del server

3

Nello spirito natalizio ho letto Cryptographic Secret Santa da MathOverflow, quindi ho seguito il link a un altro pagina intitolata Cryptographic Secret Santa .

Su quest'ultima pagina l'autore spiega un algoritmo che userebbe per assegnare Secret Santas senza bisogno di fiducia a un'autorità centrale.

Alla fine, tuttavia, l'autore scrive:

Although it's feasible for this mechanism, being used by a group of hacker friends, to be implemented with command line tools (pgp, ssh-keygen) and email lists for publishing - it's very desirable to have some sort of application (web application) to make it easier for non hacker friends to join the game.

Ora, quando raggiungiamo la nozione di Applicazione Web, l'assenza della necessità di attendibilità va fuori dalla finestra: dovrai fidarti dell'applicazione Web. Anche se hai il codice sorgente, non puoi essere certo che l'applicazione Web sia compilata dalla stessa versione del codice sorgente messo a tua disposizione.

A questo punto, lasciamo il campo dal campo pratico e consideriamo un caso puramente teorico. Supponiamo che tutti i client eseguano la propria crittografia, decrittografia, firma e verifica, quindi non devono fidarsi del server.

In questo caso teorico l'idea descritta nell'articolo potrebbe funzionare, ma c'è almeno un singhiozzo che posso individuare.

To make sure this process is correct where each participant have one and only one anonymous public key published. The number of keys should be equal to the number of participants, and each one should confirm that he/she has published the key and it's being listed (never pointing out which one is it though).

At the end of the publishing we should have an associated list with the identity public keys and the participant names, and a separate list of anonymous public keys that only each participant know which one is his/her public key, but not the others.

In questo modo sembra che le chiavi debbano essere inviate in modo anonimo, ma una parte anonima può fornire chiavi ridondanti e non ci sarà modo di dire quali chiavi sono legittime e che sono inviate da un partecipante malintenzionato. Si noti che una persona che è stata invitata a partecipare legittimamente può ancora inviare in modo malevolo più chiavi anonime e nessuno lo saprebbe, cioè se il server non deve essere considerato attendibile con le informazioni di cui è la chiave anonima

In quanto tale, sembra che questo suddivida l'intero algoritmo proposto.

Domande:

  • Il mio ragionamento suona e l'algoritmo non va bene nel senso che non c'è modo di fidarsi dell'applicazione web se la usiamo come descritto?
  • Esiste una "soluzione facile" che potrebbe consentire il suo funzionamento?
posta Andrew Savinykh 19.12.2017 - 06:29
fonte

1 risposta

0

Hai sempre bisogno di un modo sicuro per distribuire le chiavi pubbliche. Credo che il documento presuma che tu sia in grado di farlo.

Tuttavia avere questo meccanismo non significa che puoi fidarti di una singola entità. Potresti fidarti di me per darti la mia chiave pubblica ma non ti fidi di me per non rigare la santa segreta. Quindi, perché questo è ancora utile - ti fidi di ogni singolo utente per passarti le loro chiavi pubbliche, ma questa è l'unica fiducia che devi avere.

    
risposta data 19.12.2017 - 10:02
fonte

Leggi altre domande sui tag