Chiavi pubbliche sono progettate per la condivisione, l'accesso in lettura e / o la pubblicazione di una chiave pubblica va bene

Private Keys sono segreti, dovrebbero essere accessibili solo al proprietario della suddetta chiave privata.

Per guidare questo punto a casa, ripensa a tutti i siti Web HTTPS che hai visitato. In ogni caso, come parte di HTTPS, il sito ti fornisce la chiave pubblica. Quindi non solo è sicuro di pubblicarlo, è destinato a essere in questo modo. Ad esempio, se fai clic sull'icona del lucchetto verde sulla barra degli indirizzi, puoi trovare la chiave pubblica per questo sito Web (se la stai visualizzando su HTTPS)

*.stackexchange.com

Modulus (2048 bits):
af 46 03 ce c7 13 e6 2e 93 d8 56 91 b1 31 8d 0a 
22 c1 f0 eb 4f 5e ef 0d f6 20 32 b9 a4 4e 87 f9 
d2 d2 44 51 b0 df 30 50 c9 35 4e 68 19 84 fb 98 
33 aa 05 4b 7e fb 57 c5 b6 2e a8 4b 04 ca cf 5e 
2e e5 9e 1b ca b7 60 c5 58 2c b0 df c4 6b 0d b1 
2c 33 97 73 54 61 2b 9a 1b b1 dc 5d 10 a9 c4 c8 
f7 6c e3 55 6e b5 0e 61 3b 35 24 0b 89 1e 32 a2 
75 69 4e 97 40 68 ee 23 48 f2 71 9f c7 7e e2 9d 
6c 22 55 36 24 64 a4 f0 b6 52 58 5a 9a 44 e7 3b 
2a d5 ed 95 63 f8 1d a8 4d 45 9b 5d c2 f2 f9 74 
81 06 18 d5 b1 fb b0 7e 5d 50 1f 63 5c a0 73 f5 
22 b2 57 64 03 e6 b7 0f 6f b7 58 0b 57 80 56 51 
65 9f f5 09 61 63 29 62 4d 30 02 3a 64 10 2d 95 
b8 12 36 04 58 c5 d7 1d 95 e2 21 3c b0 b3 93 35 
b2 b1 f9 6d 7e 20 66 b2 68 33 e9 50 a8 15 1e 0a 
80 9a 3c 19 dd cc 79 35 a8 8c 1b 61 33 5d 12 2f 

Exponent (24 bits):
65537

Ulteriori esempi di questo possono essere trovati su github.com dove ti chiedono di allegare una chiave pubblica al tuo account per l'uso con git clone [email protected]:<user>/<repo>

Puoi effettivamente controllare le chiavi pubbliche di qualsiasi utente su github con il seguente URL

https://api.github.com/users/<user>/keys

il mio è elencato come:

[
  {
    "id": 18667533,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDraswAp7EbMwyYTzOwnSrsmr3nNMDaDf4e2YVaehLc9w6KN2ommomXZO8/V9N3yINNveGqrcVc9m2NTm04iILJUKd9o25ns8QIG6XSCt9SVx/Xw1J/SXfIWUKuEe0SgmIwVwkk8jetfG/Z7giSiU3dxxC4V9lHQCFgKOKBWGpNbINmqtmBWncX3HJKeXrpSddoePbZZ84IEFr4CWUlqoXyphpxqzpfA9sRpVTtyBPcUSj68j4+gKgEQN65G6LXys3q8BiwWxucci6s34vp4L8jKn7uYh26vLuT1oIbODJphCmpvMH+ABPkNQcFBk4rRLpCEAsoAhmvTk/NjnfZM+nd"
  },
  {
    "id": 21175800,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC5tPV481acCZ5wm2E15gXkVRaKCE3lic/O8licyzW+eDE9rPpG4rHRRH9K2ENmstUh5nLEenb0nNhEGnsf3pIJRZ07JXwv16+lsJBSS8+YiWeMBlwo+JNaxwSyUlYUgl1ruogr0nR0KBqsYSWXuG0s2jm2IOV+0B/0fzDR/tiLFLj50+iJ9qCDSk/8fAsXz2xG39KcUcxmCbDXb/qSdESWaZc+pafNRiCcVNfMkKeDViWlzI4VkiTcfVCraHUuYx4jgOBB526dRWSDG9bLchwlJiopgT+k4X/TNe2l01DPwYetwLvY6V8rcPrjjJL8ifRTMSof1zRIoBgJZhRzWc1D"
  }
]

L'esatto contrario è vero per Private Keys che devono essere protetti in ogni momento e mai ceduti a terzi o scambiati via email senza crittografarli.

Se qualcuno ha effettuato l'accesso alla tua chiave privata, ha la possibilità di accedere a qualsiasi dispositivo o file crittografato che è stato protetto con la tua chiave pubblica. Significa anche che possono firmare cose per tuo conto. È MOLTO cattivo se qualcuno ha ottenuto l'accesso alla tua chiave privata.

In molti casi i client SSH non funzioneranno se viene rilevato che le autorizzazioni del file della chiave privata sono tali che gli utenti diversi da voi hanno accesso in lettura.

Is it completely safe to publish an ssh public key?

No, ma puoi farlo comunque senza preoccupazioni (molte persone lo fanno, guarda solo link o link )

Il motivo per cui non è completamente sicuro è perché se conosco la tua chiave pubblica, posso, con un semplice pezzo di matematica, calcolare la tua chiave privata. La tua chiave pubblica contiene un numero elevato n che in pratica è il prodotto di due numeri primi, e se trovo questi due numeri primi, posso facilmente trovare la tua chiave privata.

Il motivo per cui non devi preoccuparti: è facile trovare i fattori di n quando n = 21, ma è molto più difficile quando n è un numero 4096 bit di lunghezza. Nessun matematico attualmente vivo o morto ha pubblicato un modo per considerare un numero così grande in tempi accettabili. Usando il metodo più conosciuto, saremmo tutti morti a lungo, molto prima che qualcuno trovasse i fattori che costituivano il tuo n .

Non è del tutto impossibile che qualcuno trovi una scorciatoia per il fattore numeri grandi. Se ciò accade, RSA sarà inutile. Fino ad allora, non devi preoccuparti.

SSH utilizza sia RSA (o un altro schema di firma) che Diffie Hellman (per lo scambio di chiavi di sessione). 1024 bit per lo scambio di chiavi Diffie Hellmann (che funziona matematicamente in modo leggermente diverso da RSA) potrebbe non essere più abbastanza grande. Questo perché alcune implementazioni ssh (e implementazioni ssl, se ricordo bene) che usano Diffie Hellman riutilizzano alcune costanti invece di sceglierle casualmente e una volta che qualcuno ha costruito una macchina per fare i calcoli necessari, potrebbero rompere tutta la crittografia basata su queste costanti. 1024 bit richiedono ancora un'incredibile quantità di potenza di calcolo per calcolare o calcolare logaritmi discreti (e miliardi di dollari per costruire macchine per farlo rapidamente), ma potrebbe valerne la pena per alcuni attori a livello statale, perché basta rompere qualche problema le istanze interromperanno un numero così elevato di sessioni crittografate. Tuttavia, 2048 e 4096 bit sono ancora considerati sicuri.

Lo stesso vale per le chiavi RSA; Non credo che un numero di 1024 bit sia stato ancora fattorizzato in pubblico, ma probabilmente è lì all'orizzonte, il che significa che è probabilmente possibile per le istituzioni con budget molto elevati prendere in considerazione numeri di 1024 bit ora , anche se non in grandi quantità.

(Modifica: ha chiarito il significato dell'ultimo paragrafo e corretto l'errore segnalato da RobIII)

Niente è "completamente sicuro"; la domanda è se aggiunge qualche rischio aggiuntivo .

Il protocollo SSH invia la chiave pubblica del client crittografata , solo dopo aver negoziato una chiave di crittografia di sessione simmetrica con il server. Quindi un avversario che intercetta la connessione non apprende la chiave pubblica del client. Ciò significa che la pubblicazione dà all'avversario un'informazione in più che altrimenti non avrebbero.

Ma cosa può fare l'avversario con queste informazioni aggiuntive? Bene, tutto dipende dal fatto che l'attaccante possa rompere RSA. Consideriamo due sottocasi. (Suppongo che sia il server che le chiavi RSA del client siano abbastanza grandi da essere al sicuro al primo posto - 2048 bit o più.)

L'avversario ha un attacco generale su RSA che richiede la conoscenza della chiave pubblica

Per attacco generale, intendo uno che interrompe l'RSA indipendentemente dalla chiave che usi. Ad esempio, questo sarebbe qualcosa di simile a un algoritmo efficiente per risolvere il problema RSA (ad esempio, un algoritmo di fattorizzazione primaria in tempo polinomiale ) o costruendo un pratico computer quantistico .

In questo caso non importa se pubblichi o meno la chiave pubblica del tuo cliente, perché SSH e ogni altra applicazione che utilizza RSA sarebbero completamente danneggiati. Quindi nessun rischio aggiuntivo.

L'attaccante ha un attacco contro un sottogruppo di chiavi pubbliche RSA "deboli"

Questo è un problema reale. Ci sono alcuni sistemi che, a causa di algoritmi di generazione di chiavi difettosi o generatori di numeri casuali difettosi, scelgono chiavi RSA che sono effettivamente vulnerabili agli attacchi. L'esempio più notevole è che la distribuzione Debian GNU / Linux è stata distribuita con un generatore di numeri casuali deboli per quasi due anni (da settembre 2006 a 13 maggio, 2008) . Un sondaggio del 2011 di 7,1 milioni di RSA le chiavi nell'Internet pubblico hanno rilevato che circa lo 0,4% delle 1024 chiavi pubbliche RSA che hanno visto erano deboli.

Se la chiave pubblica del cliente è una chiave così debole e la pubblichi, allora un utente malintenzionato che la ottiene può essere in grado di dirlo e sfruttare questo fatto. Saranno quindi in grado di accedere ai server SSH in cui si utilizza la chiave per l'autenticazione. Sarebbe davvero un ulteriore rischio.

Se il tuo server ha una chiave pubblica così debole, allora quel server non è sicuro; un utente malintenzionato può intercettare le connessioni, il che consente loro di imparare comunque la tua chiave pubblica. Quindi in questo caso non ci sono ulteriori rischi.

Conclusione

Il rischio aggiuntivo di pubblicare la chiave pubblica del client SSH è piccolo ma non zero. Il rischio maggiore è che la chiave pubblica del client sia debole, causata da software difettoso. Se hai intenzione di pubblicare una chiave pubblica del cliente, potresti prendere delle misure per assicurarti che la tua chiave non sia debole. Ad esempio:

• Controlla la tua chiave pubblica con un strumento per la verifica dei punti deboli
• Genera la tua coppia di chiavi dei clienti su un sistema in cui hai fatto la dovuta diligenza per assicurarti che non ti dia le chiavi deboli. Per esempio:
  • Applica tutte le patch di sicurezza al tuo sistema operativo, in particolare quelle che risolvono i problemi con il generatore di numeri casuali, SSH o qualsiasi libreria da cui SSH dipende.
  • Adottare misure per garantire che il sistema abbia accesso a una buona fonte di entropia. (Argomento complicato.)

No, a meno che non ne usi uno unico per servizio. Permette agli hacker di identificarti.

Se usi la stessa chiave pubblica per il servizio A e il servizio B, e la tua chiave pubblica viene trapelata per entrambi, questo collegherà i tuoi due account insieme.

Speriamo che nessuno dei due servizi sia imbarazzante. Ma anche in questo caso, questo darà all'attaccante un vantaggio migliore per capire quale account (i) dovrà modificare un giorno, se vuole attaccarti.

C'è un leggero rischio di rivelare la tua identità se la tua chiave pubblica contiene il tuo nome host come commento alla fine, ad es. %codice%. Se il tuo nome è abbastanza raro, potrebbe essere possibile identificarti.

Vedi questa domanda & rispondi per maggiori dettagli: Devo pubblicare la mia chiave SSH pubblica con user @ hostname alla fine?

Sì, ma ...

Se la tua sicurezza si basa sulla privateness della chiave pubblica, stai facendo qualcosa di non ottimale. Questo non è ciò per cui è stata progettata la crittografia asimmetrica.

Tutte le risposte precedenti indicano alcune vulnerabilità

• che presentano un rischio maggiore se la tua chiave pubblica è nota
• o mostrano qualche difesa aggiuntiva che hai è tenuta segreta.

In entrambi i casi, la vera ragione è che non si utilizza la chiave pubblica per la quale è stata progettata. Ad esempio, la conoscenza della tua chiave pubblica rende possibile la tua identificazione. Questo può essere gestito da pubkey nascosto, ma può essere fatto meglio se si utilizza qualche meccanismo aggiuntivo (ad esempio, un livello di crittografia aggiuntivo con coppie di chiavi casuali generate automaticamente per sessione) per questa attività.

Ma tutto può essere usato anche per altri compiti, può essere anche fruttuoso, soprattutto se non siamo dalla parte della difesa.

Right now I don't have my .ssh directory under version control. But it would save a step if I could keep .ssh/authorized_keys in the dotfile repository.

Anche se dovrebbe essere sicuro rendere pubblica la chiave pubblica, non penso che sia una buona idea:

La chiave privata è anche memorizzata nella directory .ssh e c'è il rischio che tu non stia attento a escluderla dal repository dotfile e pubblicarla accidentalmente.

Un ulteriore problema con la condivisione della chiave pubblica è se è stato generato in modo non sicuro. Sono stati pubblicati numerosi articoli sui modi in cui le chiavi RSA e Diffie Hellman possono essere backdoor ma per il resto appaiono perfettamente normali. In questo scenario, fornire la tua chiave pubblica fornirebbe a un utente malintenzionato tutte le informazioni necessarie per ricavare la tua chiave privata.

References:

link link

Ci sono diverse minacce che puoi prendere in considerazione. Uno discusso da altri rispondenti è quello di un utente malintenzionato che cerca di decifrare la chiave pubblica. Un'altra minaccia che vale la pena considerare è che questo utente malintenzionato sostituisce le sue chiavi pubbliche con la sua. Se cambia le chiavi e non te ne accorgi, puoi configurare un sistema utilizzando le chiavi dell'utente malintenzionato, quindi distribuendo la sua chiave pubblica HIS per la quale possiede la coppia privata.

Sì

Se RSA funziona come progettato, questo non dovrebbe essere un problema di sicurezza. Potrebbe rivelare un po 'di informazioni sulla tua identità, ma anche questa domanda non viene visualizzata.

Perché?

Per AES, sono necessari solo 256 bit perché la chiave è completamente segreta. Con RSA, stai dando ad un avversario alcune informazioni (la chiave pubblica), ma si può dimostrare che è ancora difficile da decifrare. Ma il factoring numera diventa più veloce più veloce delle password forzate da brute.

Simplisticamente, due numeri primi scelti casualmente sono la chiave privata, e moltiplicati insieme formano la chiave pubblica. (Questo è fattibile perché i numeri primi sono abbastanza comuni). RSA si basa sul presupposto che il fatto di ricondurli ai due numeri primi sia difficile. Ci sono stati molti progressi negli algoritmi di factoring dei numeri, e se i computer quantistici completi si presentano, l'algoritmo di Shor sarà la fine di RSA

In termini di teoria dei sistemi PKI, no. Il sistema è progettato per essere "sicuro", o più esattamente non più debole , quando sia l'algoritmo che la chiave pubblica sono noti al mondo.

In pratica, potrebbe esserci qualche esposizione per altri motivi. In breve, non compromettere la tua stessa sicurezza con errori grossolani; ed è meglio creare distinti keypair per ogni singolo scopo.

• Se si dimentica e si accusa accidentalmente la chiave privata o un certificato di revoca e qualcuno lo vede, potrebbero essere utilizzati contro di voi. Inserendo qualsiasi cosa nella tua cartella .ssh accetti il rischio di un potenziale errore umano; devi stare attento. (E se ciò accade, semplicemente cancellandolo di nuovo potrebbe non rimuoverlo dalla cronologia.) Non nei sistemi più popolari di oggi. A seconda del sistema di controllo della versione, potresti avere difficoltà a eliminarlo completamente.)
• A seconda di come è pubblico il tuo repository e su quale altra cosa usi questa chiave pubblica, le parti ostili potrebbero essere in grado di tenere traccia dell'attività svolta con quella chiave pubblica e quindi di costruire una cronologia delle tue azioni. In teoria, identificandoti nel processo. Campo lungo.