Fornire qualsiasi parte della chiave privata la rende meno sicura, almeno marginalmente, semplicemente perché fornisce a un utente malintenzionato uno spazio chiave potenziale più piccolo da esplorare.

Non riesco per capire cosa vuoi ottenere. L'unica cosa che due persone devono fare per verificare se possiedono le stesse informazioni è scambiarsi un hash.

Se stai progettando un protocollo e sei preoccupato per gli attacchi replay, puoi proteggerti eseguendo una risposta di sfida utilizzando un HMAC.

Modifica :

Come suggerito nei commenti e spiegato nella risposta perspicace di DW, devo sottolineare che l'impatto sulla sicurezza della tua chiave privata dipenderà MOLTO da quale algoritmo stiamo usando. Nello scenario peggiore, rivelare solo una piccola parte della chiave privata interromperà completamente la sicurezza di quella chiave.

Rivelare parte della chiave privata può essere catastrofico, per alcuni sistemi crittografici asimmetrici (a chiave pubblica). Il livello esatto di rischio dipende esattamente dal sistema crittografico che stai utilizzando. Alcuni esempi:

• Se stai usando RSA con e = 3 per la chiave pubblica, allora rivelare 1/4 della chiave privata (i bit bassi 1/4 di d) è abbastanza per consentire a un utente malintenzionato di ricostruire l'intera chiave privata. Ad esempio, se stai utilizzando RSA a 2048 bit e riveli i 512 bit meno significativi della chiave privata, un utente malintenzionato può recuperare il resto della tua chiave privata. Questo risultato è dovuto a Boneh, Durfee e Frankel. Ci sono altri risultati simili in letteratura (ad esempio, sui bit più significativi, un sottoinsieme casuale di bit, ecc.).

• Con DSA, se pochi bit sono trapelato dal nonce utilizzato in ogni firma (per una varietà di firme), questo è sufficiente per recuperare la chiave privata. Ad esempio, se riesci a osservare 5 bit del nonce segreto utilizzato in ciascuna delle 4000 firme, è sufficiente per 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 dicono che non è un problema. Queste risposte potrebbero presumere che tu stia utilizzando un sistema crittografico a chiave simmetrica. Per la maggior parte dei sistemi crittografici a chiave simmetrica, se riveli parte della chiave, ma una quantità sufficiente della chiave rimane non rivelata, probabilmente saranno ancora al sicuro. Quando si tratta di criptosistemi asimmetrici, le cose sono diverse. Altre risposte sembrano presumere che la forza bruta (provando esaurientemente tutte le possibili chiavi private) sia il miglior attacco possibile contro il criptosistema. Per molti sistemi crittografici asimmetrici, questo presupposto non è accurato.

Quanto più velocemente un utente malintenzionato potrebbe decifrare la chiave dati quegli 8 caratteri?

È difficile rispondere senza sapere di che tipo di chiave stiamo parlando e quale algoritmo viene utilizzato con.

Nel caso della crittografia simmetrica in cui la chiave è del tutto casuale (capire che ogni bit prende parte in egual misura nell'incertezza globale della chiave), allora dipende principalmente da ciò che "1 carattere" rappresenta in termini di dati binari. In generale, rivelando n bit , stai effettivamente riducendo il numero di chiavi possibili di un fattore di almeno 2 ^ n .

• Nel caso di una rappresentazione testuale binaria dove 1 carattere = (0 o 1) = 1 bit : 8 caratteri significa un fattore di riduzione di 2 ^ 8 = 256 .
• In caso di una rappresentazione esadecimale dove 1 carattere = 4 bit : 8 caratteri indicano un fattore di riduzione di 2 ^ 32 = 4294967296 .
• Nel caso di una rappresentazione in base64 dove 1 carattere = 6 bit : 8 caratteri significa un fattore di riduzione di 2 ^ 48 = 281474976710656 .

Che, a seconda della quantità di informazioni rivelate, può (o meno) essere utilizzato come leva per rompere la tua chiave a seconda delle possibili debolezze (attuali o future) del tuo algoritmo di crittografia.

Si noti inoltre che nel caso di crittografia asimmetrica in cui la chiave non è completamente casuale (ad es. modulo del fattore primo ed esponente in RSA), rivelare n bit potrebbe effettivamente rivelare informazioni molto più utili e possono portare a una perdita catastrofica della sicurezza.

Ma la vera domanda è:

Perché qualcuno dovrebbe mai aver bisogno di farlo?

Non solo questo metodo rappresenta una potenziale sicurezza difetto, l'affidabilità non sembra adatta al tuo scopo, che dire dei restanti 248 bit?

Il metodo che descrivi è solo una funzione hash molto banale che è completamente continua (pessima per il controllo dell'integrità) e parzialmente reversibile (pessima per scopi di sicurezza).

Se davvero deve farlo, utilizzare una funzione di hash crittografica sicura e ampiamente disponibile come SHA-256 che genererà un hash molto più sicuro (praticamente irreversibile e ad alta intensità di calcolo) e molto più resistente alle collisioni dei "primi 8 caratteri".

Se utilizzi la crittografia asimmetrica, non dovresti mai aver bisogno anche condividere qualsiasi parte (anche un hash) della chiave privata, usa invece la chiave pubblica .

Direi che va da "non critico, ma un po 'stupido" a "disastroso", a seconda del significato di "8 caratteri" e degli algoritmi utilizzati.

Se si legge " 8 caratteri "come quello che sono letteralmente, 64 bit, quindi riduci la dimensione della tua chiave di 64 bit (è un po 'meno drastico se si assume" char "come carattere codificato in base 64, allora sarebbe solo 48 bit).

Supponendo che "chiave privata" si riferisca effettivamente a un algoritmo simmetrico (improbabile?), è probabilmente tollerabile poiché 192 bit sono ben oltre la possibilità della forza bruta. Ma poi di nuovo, perché usare una chiave a 256 bit in primo luogo?

Supponendo "chiave privata, 256 bit" significa che usi una sorta di crittografia a curva ellittica (per cifrari simmetrici, "privato" poiché tutte le chiavi sono private e per RSA et al. 256 bit è troppo piccolo per essere utile), abbassi il tuo livello di sicurezza da leggermente inferiore a 128 bit (che è, al momento, irrealizzabile) a un po 'meno di 96 bit. Che è ... beh, non precisamente fattibile, ma quasi. Considerando che l'informatica quantistica non è ancora del tutto lì, ma è in arrivo, "non del tutto, ma quasi" è un po 'disastroso.
Dopo tutto, ciò che si pianifica è il caso peggiore, non il caso migliore .

È ancora più disastroso perché farlo è assolutamente, al 100% non necessario.

Se due parti condividono una chiave segreta, un metodo molto ovvio per assicurarsi che sia la stessa chiave sarebbe quello di crittografare uno schema di bit casuale sufficientemente lungo (più lungo dell'output hash), lasciare che l'altro lato decrittografi lo schema di bit e inviare un hash sicuro (ad esempio, SHA-256, SHA3, qualunque cosa) dello schema di bit.
Che la prima parte può banalmente confrontare con il risultato del calcolo dell'hash sul pattern casuale originale.

In nessun momento viene trasmessa la chiave privata (o parte di essa), o anche un hash di detta chiave (che potrebbe essere molto molto improbabile, ma forse, essere invertita o fornire un suggerimento verso una parte di essa), e poiché lì sono bit di input più casuali che bit di output, è impossibile determinare lo schema di bit originale che è stato sottoposto a hash dal valore hash e utilizzarlo per ottenere un angolo sulla crittografia.

L'attaccante può solo vedere uno schema di bit casuale per il quale ha bisogno di conoscere la chiave (sconosciuta) per ottenere l'originale e l'hash di un altro schema di bit sconosciuto che potrebbe essere uno dei tanti schemi di bit (senza modo di sapere quale).

Altri hanno già risposto di quanto l'informazione è trapelata e quindi di quanto si abbassa l'entropia per un attaccante; ed è stato notato anche il punto principale che si dovrebbe confrontare (pubblicamente) gli hash.

Tuttavia, questo presuppone che le due persone che desiderano confrontare le chiavi si fidino l'una dell'altra. Se non si fidano l'uno dell'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 restituire lo stesso hash, facendo pensare ad A erroneamente che anche B sia in possesso della stessa chiave.

Una soluzione a questo problema è che A invia hash (K) a B e si aspetta che B invii hash (non K) ad A , dove non K è il valore capovolto bit per bit di K. B può inviare questo hash ad A solo se possiede davvero K.

NOTA Quanto segue presuppone un aumento di velocità lineare (come si otterrebbe in un attacco di forza bruta): l'aumento di velocità potrebbe essere ESPONENZIALE, 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 fino ad ora) per decifrare una chiave, con l'aiuto di 8 caratteri binari, ci vorrebbero solo 0,023 secondi.

Questo è: 13,8 miliardi di anni / 2 ^{(bits_per_symbol * number_of_symbols)} .

Tu ha detto che il numero di simboli è "8 caratteri", e sto assumendo binario, che ha 8 bit per simbolo. quindi: 13,8 miliardi di anni / 2 ^{(8 * 8)}

Se sono codificati in uuenc, o in base64, avranno 6 bit per simbolo, quindi ci vorrebbero tutti 25 minuti per elaborare le combinazioni rimanenti.

Queste proporzioni si applicano solo al numero di bit che hai rivelato e non dipendono dalla lunghezza della chiave (solo che la chiave impiegherebbe 13,8 miliardi di anni per decifrare ).

Il punto centrale della crittografia a chiave pubblica è che non devi MAI MAI MAI condividere la chiave privata. Ogni chiave privata dovrebbe esistere solo in un posto e non viaggiare mai su 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, fai creare a ciascuno la propria chiave privata, invia la loro chiave pubblica (in modo sicuro !!) quindi crittografa il messaggio con entrambe le chiavi. Di solito con PKC, i messaggi lunghi vengono crittografati utilizzando la crittografia simmetrica con una chiave casuale, quindi la chiave viene 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 è dimostrare di avere la chiave privata, puoi fare quanto segue:

Chiedi alla persona a cui vuoi dimostrare di fornire un valore casuale (un "nonce") . Aggiungi un valore casuale del tuo, hash e firma l'hash. Invia indietro il tuo valore casuale e la firma.

La tua controparte prenderà quindi il nonce che ha inviato, più il tuo valore casuale, lo sottoporrà ad hashing e verificherà la firma rispetto alla tua chiave pubblica.

Includere un valore casuale dal mittente, dimostra che non hai appena selezionato un valore che è stato precedentemente firmato dal vero proprietario.

NON IN ALCUN CASO accettare qualcosa inviato da qualcun altro e firmandolo, senza modifiche. Possono inviarti l'impronta digitale di un documento che hanno scritto e tu firmerai effettivamente quel documento.

Se Alice e Bob sospettano di condividere la stessa chiave privata, perché no:

1. Alice genera nonce X.
2. Alice crittografa X a se stessa - Y.
3. Alice invia X, Y a Bob.
4. Se Alice e Bob hanno davvero la stessa chiave privata, quando Bob decrittografa Y, otterrà X. Ora Bob sa che Alice condivide la sua chiave privata.
5. Bob fa lo stesso al contrario. Ora Alice sa che Bob condivide la sua chiave privata.

Non sono un esperto di crittografia. Mi sto perdendo qualcosa?

Penso che quanto sopra soddisferà la loro domanda senza svelare i loro segreti. Eve non saprà nemmeno la risposta alla domanda.