Crittografia basata sull'identità e Open Source

Question

Recentemente ho eseguito attraverso la nozione di identità Based Encryption (IBE), che sembra una nuova idea. Tuttavia, non ho notato molti nella comunità di crittografia tentativo di trovare il modo di romperlo. Mi sbaglio?

Allo stesso modo, io sono della convinzione che se non si può effettivamente distribuire implementazioni open source dove la folla blackhat può attaccare esso, che non può avere il merito?

Credo che mi piacerebbe capire le esperienze della comunità-at-large nell'utilizzo di questo approccio e come è facile da integrare nella vostra applicazione e distribuire?

(Edit:. Ecco una Wikipedia articolo sulla crittografia basata su ID)

Answer 1

Non ho chiaro che cosa si sta cercando di fare, quindi ho intenzione di recuperare un paio di cose, e rispondo. Fatemi sapere se sto diventando caldo

In primo luogo, "l'identità di crittografia basata" in realtà non è uno schema di crittografia così tanto come un sistema di gestione delle chiavi. In ogni pubblico / privato - o, tecnicamente, "asimmetrico" - crittografia, ci sono due chiavi. Uno di essi viene utilizzato per cifrare, uno per decifrare, e hanno la proprietà speciale che se si conosce uno di loro, è ancora difficile in modo esponenziale (o pensato per essere esponenzialmente duro) per costruire l'altra. Quindi, posso ad esempio cifrare una lettera a voi utilizzando la mia chiave privata; Pubblico la mia chiave pubblica. Se si riesce a decifrare la lettera con la chiave pubblica, si ha la garanzia che io ero quello che realmente lo ha inviato. Questa è l'idea centrale dei regimi di firma digitale.

Il problema è che devi avere un modo di generare e gestire le chiavi, e che risulta essere difficile, perché lo schema è solo buono come la protezione che avete sul vostro chiave privata. Ci sono una serie di metodi per fare questo.

crittografia basata ID tenta di semplificare questo chiave problema di gestione proponendo speciali algoritmi che costruiscono privato chiavi da un pezzo pubblica conosciuta di informazioni: dicono che un indirizzo di posta elettronica. Per fare questo in un modo che rende ancora difficile capire il lato privato, è necessario disporre di un ente di fiducia che costruisce la chiave privata in base a qualche altro segreto che conoscono. Così, per stabilire le comunicazioni con qualcuno che conosce il tuo indirizzo email. si va al fornitore di fiducia e chiedere la chiave privata da generare. La persona che si desidera comunicare con sa cosa provider utilizzato, e ottiene un maestro chiave pubblica da quel fornitore.

Ora, la persona che si desidera inviare ad allora in grado di generare il lato pubblico dal tuo ID senza sapere nulla, se non un padrone informazioni chiave dal provider; la chiave non viene mai trasmessa direzione.

In altre parole, sembra che questo: Alice vuole inviare e-mail a Bob che è criptato. Entrambi fidarsi di un fornitore, Tom.

• Alice invia una richiesta a Tom con il suo indirizzo di posta elettronica "alice@example.com", e torna una chiave privata P . C'è una corrispondente chiave pubblica p , ma Tom non invia a nessuno.
• Bob invia una richiesta a Tom e ottiene chiave di Tom maestro pubblico m .
• Alice cifra il suo messaggio "x" con la sua chiave privata, dando { "x"} P . (Quella notazione è solo "messaggio "x" "avvolto" o la crittografia con chiave P .) Alice quindi invia il messaggio a Bob.
• Bon usa la sua conoscenza di indirizzo e-mail di Alice e chiave master di Tom m , e calcola. p = f ( "alice@example.com", m ). Ora egli applica il decrypt decrittazione ({ "x") P, p) e puf, viene fuori il messaggio di Alice.

La cosa di questi schemi è che semplifica alcuni problemi di gestione delle chiavi, ma solo un po '. È comunque necessario generare le chiavi, e quel che è peggio, è necessario davvero la fiducia Tom, perché lui sa tutto: può generare la chiave privata, e cifrare con essa, rendendo qualsiasi messaggio sembra ne è venuto da voi. Che cosa questo significa è che crea un sistema di key escrow intrinseca; la chiave privata può essere scoperto.

Alcuni modi questo è un bene; gestisce il problema della perdita delle chiavi. Ma per la maggior parte delle ragioni gente vuole utilizzare la crittografia, è cattivo. Ora qualcuno può citare in giudizio Tom, o semplicemente picchiarlo, e ottenere accedere ai dati personali.

Il risultato è che la crittografia da sola basato ID è un idea ingegnoso, ma non ha avuto un sacco di un mercato.

Answer 2

Charlie è sulla strada giusta, ma voglio sottolineare alcuni altri punti. (I miei commenti sono stati scritti sulla base di una versione precedente, più corta della risposta di Charlie.) IBE è più un sistema di gestione delle chiavi di un approccio alla crittografia, e il suo approccio alla gestione delle chiavi spazza le questioni importanti sotto il tappeto. Cercando di utilizzare identità di fondamento è pieno di problemi, perché nessuno ha davvero una buona soluzione per la verifica dell'identità nelle applicazioni elettroniche, sia in rete o nel mondo fisico. Senza una buona soluzione per l'identità, questi schemi IBE cadono sul loro volto una volta che lo stress le identità che si basano su.

La maggior parte dei sistemi IBE che ho visto alcun dettaglio tecnico su davvero devolvere a "fidarsi del provider", che non è scalabile e non fornisce sicurezza reale quando si ha realmente cura su di esso. Gli sforzi provider per per stabilire l'identità attraverso la rete, e quindi agisce come un terzo di fiducia, tenendo le chiavi di crittografia per tutti. Basandosi su un terzo di fiducia ha molti punti deboli conosciuti.

crittografia moderna è tutto sulla ricerca di modi per non dover fare affidamento su terze parti. Web di fiducia è un approccio, lo svantaggio principale è che lascia la gestione delle chiavi per gli utenti finali e la gestione delle chiavi è costoso. Basandosi su emittenti di certificati è un altro approccio, ma è chiaro che gli emittenti sono le persone di fiducia. Alcuni anni fa, uno dei principali problemi che tutti i browser fidati è fallita ed è stata acquistata dalla bancarotta da un giocatore che non era ovviamente degno di fiducia, mettendo in chiaro che la debolezza in tale regime è alla radice delle catene di certificati .

Answer 3

crittografia basata su identità sarebbe difficile da tirare fuori in un progetto open source, in particolare il tipo che non è solo libero come in libertà, ma libero come la birra. Come è stato detto, l'intero sistema si basa su una terza parte fidata di rilasciare le chiavi. Questo richiede infrastrutture, sia per hardware e software, che è costoso da acquistare e mantenere. Inoltre, mette un sacco di responsabilità sul partito che sta facendo il rilascio chiave. Le persone che utilizzano il sistema si aspettano l'emittente di assumersi la responsabilità quando le cose vanno male (e saranno); questo tipo di responsabilità non è a buon mercato, ed è spesso irrealizzabile per un progetto open source per assumere.

Answer 4

C'è un particolare schema che avete in mente? "Identità-Based Encryption" è piuttosto un termine ampio.

Ma in ogni caso, forse non avete visto così tanta attenzione, perché non è crittograficamente che di per sé speciale. Principi generali della crittografia sarà ancora applicabile, come ad esempio il numero di bit di entropia ci sono in chiave di crittografia? quali sono i rischi di attacchi di collisione e altri attacchi basati su avere grandi volumi di testo in chiaro / cifrato, se la stessa chiave sta per essere utilizzato per un periodo sostanzialmente indefinito di tempo ..?

Answer 5

esso . Buono e semplice soluzione.