Come verificare il numero con Bob senza che Eve lo sappia?


49

Devi verificare che il tuo amico Bob abbia il tuo numero di telefono corretto, ma non puoi chiederlo direttamente. Devi scrivere la domanda su una carta e consegnarla a Eva che prenderà la carta a Bob e ti restituirà la risposta. Cosa devi scrivere sulla carta, oltre alla domanda, per assicurarti che Bob possa codificare il messaggio in modo che Eva non possa leggere il tuo numero di telefono?

Nota: questa domanda è in un elenco di "domande per l'intervista a Google". Di conseguenza, ci sono tonnellate di versioni di questa domanda sul web e molte di esse non hanno risposte chiare o nemmeno corrette.

Nota 2: La risposta sprezzante a questa domanda è che Bob dovrebbe scrivere "chiamami". Sì, è molto intelligente, "fuori dagli schemi" e tutto il resto, ma non usa alcuna tecnica in quel campo di CS in cui chiamiamo il nostro eroe "Bob" e il suo avversario che intercetta "Eva".

Aggiornamento:
punti bonus per un algoritmo che tu e Bob potreste entrambi ragionevolmente completare manualmente.

Aggiornamento 2:
Nota che Bob non deve inviarti alcun messaggio arbitrario, ma conferma solo che ha il tuo numero di telefono corretto senza che Eva sia in grado di decodificarlo, il che potrebbe portare a soluzioni più semplici.


1
Ma "chiamami" non ha affatto senso, non ha ancora il tuo numero di telefono corretto o almeno non sei sicuro che lo sia, quindi non penso che sia molto intelligente.
Gigili

1
@Gigili se ricevi una chiamata da lui, allora ha il tuo numero, se non ricevi una chiamata, non lo fa.
Joe

1
Oh giusto. Penso ancora che non sia intelligente!
Gigili

Un'altra risposta ironica potrebbe essere la cifra di Cesare . Anche se Eva prova tutti i possibili offset, non ha motivo di scegliere una sequenza di cifre piuttosto che un'altra (a meno di provare a chiamarle tutte).
Raffaello

2
@Raphael Non ci sono solo 10 possibili cifre di Cesare su cifre?
Joe

Risposte:


27

Innanzitutto dobbiamo supporre che Eva sia solo passiva. Con questo intendo dire che spedisce sinceramente la carta a Bob, e qualunque cosa lei riporti ad Alice è davvero la risposta di Bob. Se Eva può modificare i dati in una o entrambe le direzioni (e la sua azione rimane inosservata), allora tutto va bene.

(Per onorare le tradizioni di lunga data, le due parti oneste coinvolte nella conversazione si chiamano Alice e Bob. Nel tuo testo hai detto "tu". Il mio vero nome non è "Alice", ma risponderò come se stessi scrivendo che Alice vuole verificare il numero di telefono di Bob.)

La risposta semplice (ma debole) è usare una funzione hash. Alice scrive sulla carta: "restituiscimi l'hash SHA-256 del tuo numero di telefono". SHA-256 è una funzione hash crittografica ritenuta sicura, per quanto riguarda le funzioni hash. Calcolarlo a mano sarebbe noioso ma comunque fattibile (sono circa 2500 operazioni a 32 bit, in cui ogni operazione è un'aggiunta, uno spostamento o rotazione di parole o una combinazione di bit bit a bit; Bob dovrebbe essere in grado di farlo in un giorno o così).

Cosa c'è di debole in questo? SHA-256, essendo una funzione hash crittografica, è resistente alle "preimmagini": ciò significa che dato un output hash, è molto difficile recuperare un input corrispondente (questo è il problema che Eva affronta). Tuttavia, "molto difficile" significa "il metodo più semplice è la forza bruta: provare possibili input fino a quando non viene trovata una corrispondenza". Il problema è che la forza bruta è facile qui: non ci sono così tanti numeri di telefono possibili (in Nord America, sono 10 cifre, cioè solo 10 miliardi). Bob vuole fare le cose a mano, ma non possiamo presumere che Eva sia così limitata. Un PC di base può provare alcuni milioni di hash SHA-256 al secondo, quindi Eva verrà eseguita in meno di un'ora (meno di 5 minuti se utilizza una GPU).

Questo è un problema generico: se Bob è deterministico (cioè per un determinato messaggio di Alice, restituirebbe sempre la stessa risposta), Eva può simularlo. Vale a dire, Eva sa tutto di Bob tranne il numero di telefono, quindi gestisce virtualmente 10 miliardi di Bob, che differiscono solo per il numero di telefono presunto; e aspetta che uno dei Bob virtuali ritorni qualunque cosa il vero Bob sia effettivamente tornato. Il difetto riguarda molti tipi di soluzioni "intelligenti" che coinvolgono nonces casuali e crittografia simmetrica e quant'altro. È un grosso difetto e la sua radice sta nell'enorme differenza nella potenza di calcolo tra Eva e Bob (ora, se Bob avesse anche un computer grande come quello di Eva, allora potrebbe usare un lentofunzione hash attraverso l'uso di molte iterazioni; questo è più o meno ciò che riguarda l'hashing della password, con il numero di telefono al posto della password; vedi bcrypt e anche questa risposta ).

Quindi, una soluzione non debole deve comportare una certa casualità da parte di Bob: Bob deve lanciare una moneta o lanciare dadi ripetutamente e iniettare i valori nei suoi calcoli. Inoltre, Eva non deve essere in grado di svelare ciò che Bob ha fatto, ma Alice deve esserlo, quindi alcune informazioni vengono trasmesse in modo sicuro da Bob ad Alice. Questo si chiama crittografia asimmetrica o, almeno, accordo di chiave asimmetrica. L'algoritmo più semplice di quella classe da calcolare, ma ancora ragionevolmente sicuro, è quindi RSA con il padding PKCS # 1 v1.5 . RSA può usare come esponente pubblico. Quindi il protocollo va così:e=3

  • Alice genera un intero grande dove e sono numeri primi di dimensioni simili, in modo tale che la dimensione di sia sufficiente per garantire la sicurezza (ovvero almeno 1024 bit, a partire dal 2012). Inoltre, Alice deve disporre che e non siano multipli di 3.p q n p - 1 q - 1n=pqpqnp1q1

  • Alice scrive sulla carta.n

  • Bob prima inserisce il suo numero di telefono in una sequenza di byte fintanto che , come descritto da PKCS # 1 (ciò significa: 00 02 xx xx ... xx 00 bb bb .. bb, dove "bb" sono i dieci byte che codificano il numero di telefono e "xx" sono valori di byte casuali diversi da zero, per una lunghezza totale di 128 byte se è un numero intero a 1024 bit).nnn

  • Bob interpreta la sua sequenza di byte come un grande valore intero (codifica big-endian) e calcola (quindi sono un paio di moltiplicazioni con interi molto grandi, quindi una divisione, il risultato è il resto della divisione). È ancora fattibile a mano (ma, di nuovo, probabilmente ci vorrà la parte migliore di una giornata). Il risultato è ciò che Bob rimanda ad Alice.m 3 m o d nmm3 mod n

  • Alice usa la sua conoscenza di e per recuperare dal inviato da Bob. La pagina di Wikipedia su RSA ha alcune spiegazioni ragionevolmente chiare su questo processo. Una volta che Alice ha , può rimuovere il padding (i 'xx' sono diversi da zero, quindi il primo byte 'bb' può essere posizionato in modo inequivocabile) e quindi ha il numero di telefono, che può confrontare con quello che aveva.q m m 3 m o d n mpqmm3 mod nm

Il calcolo di Alice richiederà un computer (ciò che fa un computer è sempre elementare e fattibile a mano, ma un computer è diabolicamente veloce, quindi il "fattibile" potrebbe richiedere troppo tempo per essere messo in pratica; la decodifica RSA a mano richiederebbe molti settimane).

(In realtà potremmo avere un calcolo manuale più veloce usando la crittografia McEliece , ma poi la chiave pubblica - ciò che Alice scrive sulla carta - sarebbe enorme e una carta semplicemente non lo farebbe; Eva dovrebbe trasportare un libro intero di cifre.)


1
Solo un breve commento, un'altra debolezza nel primo protocollo (Alice dice "mandami un hash del numero di telefono") è che è vulnerabile a un attacco di risposta. Se lo stavi implementando nel mondo reale, Alice dovrebbe inviare una stringa casuale (chiamata "nonce") che viene l'hash con il numero di telefono.
Pseudonimo del

1
Hai detto che "tutto va bene" se Eva può modificare il messaggio, ma questa non è necessariamente una causa persa. Utilizzando RSA possiamo effettivamente proteggere il messaggio anche dagli attacchi MITM. Invia una domanda: "Hai il mio numero di telefono?", Più la tua chiave pubblica, più una firma di (messaggio + il tuo numero di telefono) firmata con la tua chiave privata. Se Eva tenta di modificare il messaggio (cambia la chiave pubblica nella propria) non sarà in grado di generare una firma valida poiché non conosce il tuo numero di telefono.
Stevendesu,

15

Sembra un'applicazione classica del sistema crittografico a chiave pubblica come RSA .

Invia la tua chiave pubblica, BoB crittografa il tuo numero di telefono dal suo elenco di contatti e te lo restituisce.


5
Considerati Bob ed Eva, questa probabilmente dovrebbe essere l'idea chiave. È pratico in questo contesto (matita e carta)? Inoltre, speravo in qualcosa di più di un link a un articolo di Wikipedia con un flag "questo articolo ha bisogno di essere modificato".
Joe

@Joe: ho modificato per includere un altro collegamento. Sono abbastanza sicuro che tu abbia sentito parlare di RSA. RSA è probabilmente abbastanza pratico, poiché la scrittura dice che 1000 cifre non dovrebbero richiedere molto tempo.
Aryabhata,

14

Una delle cose più basilari che puoi fare è uno scambio di chiavi Diffie-Hellman . Non è necessario che tu abbia le chiavi impostate prima che inizi la comunicazione poiché ne negozia una in modo tale che gli ascoltatori non possano ricavare la chiave da soli. Vedi l' articolo completo di Wikipedia per i dettagli.

pgpggamodpa

  • gbmodpb
  • gabmodp

gamodpgbmodpgabmodp

Finché implementato correttamente e sia i comunicatori che gli attaccanti hanno a disposizione la stessa potenza di calcolo, questo è sicuro.


2

Bob non deve inviare alcun messaggio che puoi decrittografare. Deve solo dimostrarti che ha il tuo numero di telefono. Pertanto, Cryptographic Hash Functions , (crittografia unidirezionale) offre un'alternativa a un sistema crittografico a chiave pubblica. SHA-2 è attualmente un esempio popolare di tale funzione.

In questa strategia, non devi mai decifrare il messaggio di Bob. Di 'a Bob quale funzione hash vorresti che usasse, ad es. "Bob, ti preghiamo di usare SHA-2 per crittografare il mio numero di telefono e chiedere a Eve di restituirmi il risultato". Quindi usi lo stesso algoritmo per eseguire l'hashing del tuo numero di telefono e controllare se ottieni lo stesso hash di Bob. È estremamente improbabile che due numeri di telefono diversi provochino lo stesso hash, quindi puoi determinare se Bob ha il tuo numero di telefono corretto.

Se tu, Bob ed Eva non avete computer disponibili per calcolare la funzione hash (o eseguire un attacco di forza bruta), potrebbe essere possibile usare la funzione di hash che sacrifica un po 'di sicurezza contro gli attacchi di forza bruta ma è molto più facile per voi e Bob calcolare.


Stavo scrivendo la stessa risposta! Sfortunato. Lo pubblicherò comunque mentre ci passavo del tempo.
Gigili

@Gigili Speravo che qualcuno potesse scrivere questa risposta, ma ho deciso di farlo quando ho visto che nessuno stava ancora offrendo questa alternativa ... Sto ancora cercando una versione per matita e carta. Onestamente, non vorrei chiedere al mio amico di fare RSA o SHA-2 a mano.
Joe

Il problema è che ogni semplice algoritmo che può essere fatto a mano verrebbe crittografato da Eva.
Gigili

@Gigili vuoi dire "decifrato da Eva"? Il problema è molto limitato. Sembra che ci dovrebbe essere un hash unidirezionale più semplice da numeri interi a 7 cifre che Eva non può semplicemente annullare per recuperare il numero originale.
Joe

Oops, intendevo ovviamente decifrato.
Gigili

0

Una soluzione semplice sarebbe:

Sia Alice che Bob concordano sullo stesso colore. e non è un problema se Eva lo sa, lo chiameremo P. Diciamo che è giallo. Ora, sia Alice che Bob scelgono a caso un colore privato, dite "x". Alice sceglie il rosso e Bob sceglie il blu. Ora li mescolano insieme al P. Alice ora ha l'arancia e Bob ha il verde. Alice invia il colore arancione a Bob, e Bob invia il suo colore verde ad Alice Eve ora conosce il giallo, l'arancione e il verde, ma Alice conosce anche il suo colore privato rosso e Bob conosce il suo colore privato blu, che nessun altro conosce. Sia Alice che Bob prendono i loro colori privati ​​originali e li aggiungono a quelli che hanno appena scambiato. Ora, se mescolano i loro colori privati ​​originali, rosso e blu, nel colore condiviso, finiscono entrambi con lo stesso colore, una specie di marrone o rosso mattone.

Invece di mescolare i colori insieme, potresti usare tale che p sia un numero primo grande e g sia una radice primitiva di p perché se fai per qualsiasi x, il risultato (un numero compreso tra zero e p - 1) è ugualmente probabile che sia uno di quelli, ecco perché c'è una radice primitiva. se p è un numero primo 2n + 1 tale che n è anche primo, allora sai che 2 è una radice primitiva di p (il che significa che non devi preoccuparti di calcolare la radice primitiva, che è un po 'difficile) quindi il segreto condiviso = per Bob e per Alice.gx(modp)A xgx(modp)B yAx(modp)By(modp)


Penso che tu possa scrivere qualcosa del genere sulla carta:

Il numero è multiplo di 3,5 e 7 (ad esempio).

Ci sono ( è il numero di cifre) possibilità e quell'idea invaliderà solo alcune poche possibilità per chi ne ha idea. Quindi la decrittazione di Eva non accadrà. n(10)nn


Questa è una narrazione dell'immagine trovata nell'articolo di Wikipedia dello scambio di chiavi Diffie-Hellmann . Dovresti almeno menzionare la tua fonte.
Raffaello

@Raphael: Non lo sapevo da solo, qualcuno me lo ha spiegato e ho pensato che fosse una buona idea.
Gigili

0

Basta chiedere a Bob di moltiplicare il numero per 2 o 3 o qualsiasi altra cosa e xor quel numero con il numero stesso. È fattibile a mano e reversibile se il numero è noto. No sha, rsa o md5. Solo semplici calcoli.


3
Questa risposta è sbagliata Semplice, fattibile a mano e totalmente insicuro. Semplicemente non funziona. Eve può recuperare molte informazioni sul numero di telefono da questo.
DW

0

Invia a Bob una parola in codice crittografata con il tuo numero di telefono; se ti restituisce la parola in codice sai che ha il numero corretto.

Il punto debole è che Eva può simulare Bob, quindi prova tutti i numeri di telefono fino a quando non ottiene quello che dà la parola in codice al ritorno di Bob.

Quindi chiedi a Bob di aggiungere un numero casuale molto grande alla parola in codice, quindi crittografalo prima di inviarlo di nuovo a te. Questo rende lo spazio di ricerca di Eves grande quanto desideri.


Questo non sembra giusto. Se Bob ha il numero sbagliato, prima decifrerà e otterrà una parola in codice errata. Dopodiché aggiunge un numero casuale alla parola chiave e crittografa con la chiave sbagliata. Quando il messaggio viene ricevuto e decrittografato con la chiave corretta, il primo segmento del messaggio recuperato può eventualmente essere la parola in codice corretta anche se il numero che Bob ha sbagliato.
Informato il

@randomA Devi solo fare in modo che le parole in codice siano sufficientemente lunghe da consentire che la probabilità che ciò accada sia così piccola che non ti interessa.
Ian Ringrose,

Quello che hai detto è vero, ma la soluzione scelta è anche molto bella su questo problema. Non sarei d'accordo con la soluzione scelta da parte di "quindi alcune informazioni vengono trasmesse con fiducia da Bob ad Alice". Se si utilizza un messaggio di riempimento sufficientemente grande e non contiene alcun simbolo utilizzato per rappresentare il numero di telefono, allora Bob può inserire casualmente il numero di telefono al suo interno e Alice può facilmente recuperare il numero di telefono dal messaggio decrittografato senza conoscere i passaggi casuali di Bob ( in questo caso non sono necessarie informazioni trasmesse in modo confidenziale).
Informato il

-1

Scriverò circa 10 numeri di telefono nella scheda e tra questi farò in modo che il mio numero venga vicino al numero di Bob e menzionerò "Ehi Bob, il mio numero è vicino al tuo numero, per favore verifica" :)


1
supponendo che conosco il numero di bob e la vigilia no: P
everlasto

-1

Penso che la domanda sia molto più semplice di quanto tutti pensino. Ci viene richiesto di verificare che il numero che Bob ha sia corretto (o, come potrebbe essere, errato). Dato che stiamo "controllando" se il numero è corretto, si può presumere che Bob abbia già il tuo numero. Pertanto non è necessario inviare a Bob il tuo numero in un codice. La mia risposta sarebbe: "Caro Bob, per favore, telefona al mio numero. Grazie, Alice"


1
La domanda esclude già esplicitamente questa banale risposta.
David Richerby,

-2

prova a fare una rappresentazione trik come questa

soluzione1: se il numero è 37 la mappa hash sarebbe simile a questa

01 07

15 12

25 20

31 36

49 43

53 50

60 62

72 72

85 82

91 94

e fare lo stesso per 10 cifre o anche di più solo per confondere: P

soluzione2: o costruisci un polinomio in cui il tuo numero diventa un altro numero univoco

solution3: scrivi questo nella lettera "amico chiamami"

soluzione4: scrivi una funzione in modo tale da eseguire operazioni su ogni cifra e restituisca 0, quindi invia una soluzione vera o falsa5: se entrambe le estremità condividono una funzione hash comune ... semplifica la vita


Non è affatto ovvio come il tuo schema codifichi 37.
David Richerby,

tutto ciò che dobbiamo fare è mappare ... 31 in grassetto significa 3 è in posizione 1 .... 72 significa 7 è in posizione 2 ... scusate se non era molto intuitivo da capire
Ajay Reddy

Questo dovrebbe essere spiegato in dettaglio nella risposta. Ma, seriamente, se questo è il tuo schema di codifica, non è esattamente sicuro, vero?
David Richerby,

-2

Penso che possiamo farlo usando operazioni sagge di base o che possiamo personalizzarlo per lavori su carta e matita. Se il numero di alice è per esempio: 663 di quello che può semplicemente convertire il numero usando questa metodologia. Converti ogni cifra in una rappresentazione binaria equivalente dillo come A 663-> 110 110 011 di invertendo i bit corrispondenti per ogni singolo numero dillo come B-> 011 011 110 Ora esegui A e B-> 010 010 010 Ora invia questo numero a bob e chiedi di fare lo stesso se il risultato arriva lo stesso chiedi a lui di dire sì oppure no. In questo caso vigilia non sarà in grado di decodificare il numero e c'è una probabilità molto bassa di avere numeri diversi che finiscono con questa stessa rappresentazione. L'unico modo in cui Eva poteva indovinare è scrivere tutte le possibili combinazioni e poi provarle tutte, ma per soddisfare il fatto che possiamo complicare ulteriormente questo problema usando lo spostamento sinistro o destro e aggiungendo bit fittizi.


Questo non funziona Innanzitutto, il bit centrale di ciascun gruppo a 3 bit non viene toccato. In secondo luogo, il primo e il terzo bit di ciascun gruppo del messaggio trasmesso saranno sempre gli stessi, e in genere zero, il che porterà a molti falsi positivi. Terzo e fatalmente, tre bit possono rappresentare solo otto valori, ma una cifra decimale può assumere uno qualsiasi di dieci valori. In quarto luogo, la tua ultima frase è essenzialmente "Oh, e se non funziona, prova qualcosa di più complesso." Ad esempio?
David Richerby,

-3

Per favore, chiamami (mi chiamo 1001001). Se non riesci a contattarmi, annota il numero di telefono che hai e chiedi a Eva di restituirmi.

Spiegazione: se Bob ha il mio numero corretto, può raggiungermi, quindi so che è un numero corretto; se Bob non ha ottenuto il mio numero corretto, Eva non può leggere anche il mio numero di telefono (corretto). In questo modo, ho già verificato che il mio amico, Bob, abbia il mio numero di telefono corretto o meno.


a everlasto: Eva può contattare Bob in modo che molto probabilmente abbia il suo #. Pertanto, se chiedi "Ehi Bob, il mio numero è vicino al tuo numero, per favore verifica", Eve ti riconoscerà #.
Pobol Wong,

1
La domanda dice esplicitamente che non puoi semplicemente inviare a Bob una carta che dice "chiamami". E Bob che scrive il numero errato sulla carta se non è riuscito a passare non aggiunge nulla.
David Richerby,

Ho scritto un programma di codifica / decodifica LZW prima. Potrei chiedere a Bob di usarlo per inviarmi il numero codificato del mio telefono e anche di usarlo per codificare la parte corretta del mio telefono # per lui.
Pobol Wong,

a David Richerby: la domanda menziona solo "non puoi chiederglielo direttamente", il che significa che io, 1001001, non posso chiedere direttamente a Bob, ma dovrebbe essere in grado di chiedergli di chiamarmi con il numero di telefono che ha ricevuto.
Pobol Wong,

Leggi la domanda più attentamente. "Nota 2" nella domanda rifiuta la soluzione di inviare una nota chiedendo a Bob di chiamarti perché non utilizza alcuna scienza informatica.
David Richerby,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.