Se due persone vogliono verificare di avere la stessa chiave privata (ad esempio 256 bit), quanto è grande il rischio di condividere il primo dire 8 caratteri su un canale potenzialmente pubblico?
Un utente malintenzionato può recuperare più informazioni rispetto a quei caratteri e / o quanto più velocemente un hacker potrebbe crackare la chiave in base a questi 8 caratteri?
Fornire qualsiasi parte della chiave privata lo rende meno sicuro, almeno marginalmente, semplicemente perché fornisce a un utente malintenzionato uno spazio chiave potenziale più piccolo da esplorare.
Non riesco a capire cosa vuoi ottenere. L'unica cosa che due persone devono fare per verificare se hanno le stesse informazioni è scambiarsi un hash.
Se stai progettando un protocollo e sei preoccupato per gli attacchi di riproduzione, puoi proteggerti eseguendo una risposta di prova usando un HMAC.
Modifica :
Come suggerito dai commenti e spiegato nella risposta perspicace di DW , ho bisogno di sottolineare che l'impatto su la sicurezza della tua chiave privata dipende molto da quello che stai usando. Nel peggiore dei casi, che rivela solo una piccola parte della chiave privata interromperà completamente la sicurezza di quella chiave.
Rivelare una parte della chiave privata può essere catastrofica, per alcuni criptosistemi asimmetrici (a chiave pubblica). L'esatto livello di rischio dipende esattamente da quale crittosistema si sta utilizzando. Alcuni esempi:
Se si utilizza RSA con e = 3 per la chiave pubblica, è sufficiente rivelare 1/4 della chiave privata (i bassi 1/4 bit di d) per consentire a un utente malintenzionato di ricostruire l'intera chiave privata . Ad esempio, se si utilizza RSA a 2048 bit e si rivelano i 512 bit meno significativi della chiave privata, un utente malintenzionato può recuperare il resto della propria chiave privata. Questo risultato è dovuto a Boneh, Durfee e Frankel. Ci sono altri risultati simili in letteratura (ad es. Sui bit più significativi, un sottoinsieme casuale di bit, ecc.).
Con DSA, se alcuni punti sono trapelati dal nonce utilizzato in ogni firma (per una varietà di firme), questo è sufficiente per recuperare la chiave privata. Ad esempio, se è possibile osservare 5 bit del nonce segreto utilizzato in ognuna delle 4000 firme, è sufficiente recuperare una chiave privata ECDSA a 384 bit. Questo non sta rivelando esattamente la chiave privata (sta rivelando qualche altro valore segreto generato durante la firma), ma è simile.
Mi rendo conto che altre risposte stanno dicendo che non c'è problema. Queste risposte potrebbero presumere che tu stia utilizzando un crittosistema a chiave simmetrica. Per la maggior parte dei crittosistemi a chiave simmetrica, se si rivela parte della chiave, ma una parte sufficiente della chiave rimane non rivelata, è probabile che siano ancora al sicuro. Quando si tratta di crittosistemi asimmetrici, le cose sono diverse. Altre risposte sembrano presupporre che la forza bruta (cercando esaustivamente tutte le possibili chiavi private) sia il miglior attacco possibile contro il criptosistema. Per molti crittosistemi asimmetrici, questa ipotesi non è accurata.
How much faster could an attacker crack the key given those 8 chars?
È difficile rispondere senza sapere di che tipo di chiave stiamo parlando e con quale algoritmo è usato.
Nel caso di una crittografia simmetrica in cui la chiave è del tutto casuale (capire che ogni bit prende una parte uguale nell'incertezza globale della chiave), dipende principalmente da cosa "1 char" rappresenta in termini di dati binari.
In generale, rivelando n bits , stai effettivamente riducendo il numero di possibili chiavi di un fattore di almeno 2^n .
1 character = (0 or 1) = 1 bit : 8 caratteri significa un fattore di riduzione di 2^8 = 256 . 1 character = 4 bits : 8 caratteri significa un fattore di riduzione di 2^32 = 4294967296 . 1 character = 6 bits : 8 caratteri significa un fattore di riduzione di 2^48 = 281474976710656 . Quale - a seconda della quantità di informazioni rivelate - può (o non può) essere usato come leva per infrangere la tua chiave a seconda delle possibili debolezze (attuali o future) dell'algoritmo di crittografia.
Si noti inoltre che nel caso della crittografia asimmetrica in cui la chiave non è completamente casuale (ad es. modulo fattore primo ed esponente in RSA), rivelare n bits potrebbe rivelare informazioni molto più utili e potrebbe portare a una perdita di sicurezza catastrofica.
Ma la vera domanda è:
Why would anyone ever need to do that ?
Non solo questo metodo pone un potenziale difetto di sicurezza, non sembra che l'affidabilità sia adatta al tuo scopo, che dire dei restanti 248 bit?
Il metodo che descrivi è solo una funzione di hash molto banale che è completamente continua (molto male per il controllo di integrità) e parzialmente reversibile (molto male per motivi di sicurezza).
Se veramente devi farlo, usa una funzione di hash crittografica sicura e ampiamente disponibile come SHA-256 che genererà un hash che è molto più sicuro (praticamente irreversibile e computazionalmente intensivo) e molto più resistente alla collisione di "i primi 8 caratteri".
Se utilizzi la crittografia asimmetrica, non dovresti mai aver bisogno di condividere parti (anche un hash) della chiave privata, usa la chiave pubblica invece .
Direi che va da "non critico, ma abbastanza stupido" a "disastroso", a seconda di cosa significhi "8 caratteri" e in base a quali algoritmi vengono utilizzati.
Se si leggono "8 caratteri" come sono letteralmente, 64 bit, si riducono le dimensioni della chiave di 64 bit (è un po 'meno drastico se si assume "char" come carattere codificato in base 64, quindi solo essere 48 bit).
Supponendo che la "chiave privata" si riferisca effettivamente a un algoritmo simmetrico (improbabile?), è probabilmente tollerabile dato che 192 bit sono ben oltre la possibilità per la forza bruta. Ma poi di nuovo, perché usare una chiave a 256 bit in primo luogo?
Supponendo che la "chiave privata, 256 bit" significhi che usi una curva crittografica ellittica di ordinamento (per i cifrari simmetrici, "privato" ha poco senso poiché tutti i tasti sono privati, e per RSA et al. 256 bit è troppo piccolo per essere utile), si riduce il livello di sicurezza da leggermente al di sotto di 128 bit (che è, attualmente, non fattibile) a un po 'meno di 96 bit. Che è ... beh, non proprio fattibile, ma quasi. Considerando che l'informatica quantistica non è ancora lì, ma sulla sua strada, "non del tutto, ma quasi" è un po 'disastrosa.
Dopo tutto, quello che si prefigge è il caso peggiore, non il best case .
È disastroso ancor più di quanto sia assolutamente, al 100% inutile.
Se due parti condividono una chiave segreta, un metodo molto ovvio per assicurarsi che sia la stessa chiave sarebbe quello di crittografare un modello di bit casuale sufficientemente lungo (più lungo dell'output), lasciare che l'altra parte decifri il modello di bit e inviare indietro un hash sicuro (ad esempio, SHA-256, SHA3, qualunque sia) del modello di bit.
Quale prima parte può essere paragonata banalmente al risultato del calcolo dell'hash sul modello casuale originale.
In nessun momento è trasmessa la chiave privata (o parte di essa), o anche un hash di detta chiave (che potrebbe essere molto improbabile, ma possibilmente, essere invertita o fornire un suggerimento verso una parte di essa), e da lì sono più bit di input casuali dei bit di output, è impossibile determinare il modello di bit originale che è stato cancellato dal valore hash e utilizzarlo per ottenere un angolo sulla crittografia.
L'autore dell'attacco può vedere solo uno schema a bit casuale per il quale ha bisogno di conoscere la chiave (sconosciuta) per ottenere l'originale e l'hash di un altro pattern di bit sconosciuto che potrebbe essere uno dei molti pattern a bit (senza alcun modo di sapendo quale).
Altri hanno già risposto di quanto trapelano le informazioni e quindi di quanto l'entropia sia abbassata per un attaccante; e il punto principale che si dovrebbe confrontare (pubblicamente) hash è stato notato anche.
Tuttavia, questo presuppone che le due persone che desiderano confrontare le chiavi si fidino l'una dell'altra. Se non si fidano l'un l'altro, il problema è che se A invia hash (K) a B, B può sapere che A ha lo stesso, o un K diverso da B, ma può imbrogliare e rimandare lo stesso hash, facendo erroneamente pensare che B sia anche in possesso della stessa chiave.
Una soluzione a questo problema è che A manda hash (K) a B, e si aspetta che B invii hash (non K) ad A, dove non K è il valore lanciato a bit bit di K. B può solo inviare questo hash a A se possiede davvero K.
NOTA Quanto segue presuppone un aumento lineare (come si otterrebbe in un attacco a forza bruta) - la velocità potrebbe essere EXPONENTALMENTE PIÙ, a seconda dell'algoritmo.
È molto difficile comprendere grandi numeri - anche io sono rimasto sorpreso quando è arrivata la risposta. Ecco un modo di pensarci:
Se, senza alcuna informazione, ci vorrebbero 13,8 miliardi di anni (l'età dell'universo finora) per craccare una chiave, con l'aiuto di 8 caratteri binari, ci vorrebbero solo 0,023 secondi.
Questo è: 13,8 miliardi di anni / 2 (bit_per_symbol * numero_di_simbolo) .
Hai detto che il numero di simboli è "8 caratteri" e presumo che sia binario, che ha 8 bit per simbolo. quindi: 13,8 miliardi di anni / 2 (8 * 8)
Se sono codificati in uuencode o base64, avranno 6 bit per simbolo, quindi impiegherebbero 25 minuti per lavorare sulle combinazioni rimanenti.
Queste proporzioni si applicano solo al numero di bit che hai rivelato, ed è indipendente dalla durata della chiave (solo che la chiave impiegherebbe 13.8 miliardi di anni per craccare).
L'intero punto della crittografia a chiave pubblica è che non è MAI MAI necessario condividere la chiave privata. Ogni chiave privata dovrebbe esistere solo in un posto e non viaggiare mai attraverso una rete. L'invio di chiavi va contro il principio stesso della crittografia a chiave pubblica. Non è MAI necessario inviare chiavi private, parzialmente o in altro modo.
Se vuoi che due (o più) dispositivi diversi siano in grado di decodificare lo stesso messaggio, ciascuno di essi crea la propria chiave privata, ti invia la sua chiave pubblica (in modo sicuro !!) quindi cripta il messaggio con entrambe le chiavi. Solitamente con PKC, i messaggi lunghi vengono crittografati utilizzando la crittografia simmetrica con una chiave casuale e la chiave viene quindi crittografata con PKC e inviata con il messaggio; puoi facilmente crittografare la chiave casuale con più chiavi pubbliche e inviarle tutte con lo stesso messaggio.
Se tutto ciò che vuoi fare è mostrare la tua chiave privata, puoi fare quanto segue:
Chiedi alla persona che vuoi dimostrare di fornire un valore casuale (un "nonce"). Aggiungi il tuo valore casuale, cancellalo e firma l'hash. Invia il tuo valore casuale e la firma indietro.
La tua controparte prenderà il nonce che hanno inviato, più il tuo valore casuale, lo cancellerà e controllerà la firma con la tua chiave pubblica.
Includendo un valore casuale dal mittente, dimostra che non hai appena selezionato un valore che è stato precedentemente firmato dal proprietario reale.
NON SOTTO QUALSIASI CIRCOSTANZA accettare qualcosa inviato da qualcun altro e firmarlo, senza alcuna modifica. Possono inviarti l'impronta digitale di un documento che hanno scritto e firmerete in modo efficace quel documento.
Se Alice e Bob sospettano che condividano la stessa chiave privata, allora perché no:
Non sono un esperto di crittografia. Mi manca qualcosa?
Penso che quanto sopra soddisferà la loro domanda senza esporre i loro segreti. Eve non conoscerà nemmeno la risposta alla domanda.
Leggi altre domande sui tag key-management