Un utente può verificare la qualità / sicurezza dei parametri dei moduli SSH pregenerati?

Question

Un utente può verificare la qualità / sicurezza dei parametri dei moduli SSH pregenerati?

#1 da (1 voti)
#2 da (0 voti)

2

Molti tutorial su come mitigare il Logjam consiglia rigenerazione moduli Diffie-Hellman. Questa operazione richiede molte risorse, in particolare per i gruppi di bit elevati.

Questo mi ha fatto pensare se avesse senso costruire un piccolo servizio che offrisse file di moduli per il download, rigenerato settimanalmente o giù di lì. OpenSSH offre un modo per verificare la sicurezza dei primi generati con l'opzione -T del ssh-keygen util , quindi un utente dovrebbe essere in grado di verificare che i primi siano sicuri. Ciò richiede molto meno tempo rispetto alla generazione di molti candidati e al controllo di numeri primi sicuri in questi.

Ora la mia domanda è: questa procedura è in realtà sufficiente per verificare che un file di moduli estranei non sia stato "backdoor" in qualche modo? Potrebbe un attaccante inserire valori appositamente predisposti, consentendo loro di interrompere lo scambio di chiavi, senza che l'utente se ne accorga?

ssh key-exchange diffie-hellman

posta tarleb 13.01.2016 - 10:59

fonte

2 risposte

Leggi altre domande sui tag ssh key-exchange diffie-hellman

Le prestazioni di Panopticlick per Tor Browser non sono eccezionali. Perché? privacy: quali parti dell'URL sono protette da HTTPS? [duplicare]

score 1 · Answer 1

Grazie a @StackzOfZtuff per gli articoli collegati. Usando quelli, questo è quello che ho messo insieme ormai:

I parametri generati possono probabilmente essere considerati attendibili fintanto che vengono rigenerati frequentemente. Per una maggiore sicurezza, bisognerebbe controllare i parametri riutilizzati, il che potrebbe essere un segnale che qualcosa di strano sta succedendo. È ancora più sicuro generare parametri sulla propria macchina.

Come suggerisce il nome, i primati sicuri funzionano bene quando si generano gruppi DH, in quanto garantiscono una certa dimensione del gruppo risultante. I numeri primi così deliberatamente cattivi, con conseguente riduzione delle dimensioni del gruppo, non sono un problema con lo schema descritto nella domanda.

L'unico possibile attacco che vedo è che l'entità generatrice potrebbe scegliere gruppi specifici e precalcolare il più possibile per risolvere il problema del logaritmo discreto usando il setaccio di campo naturale . Ciò renderebbe molto più semplice per un utente malintenzionato interrompere qualsiasi DH utilizzando quel gruppo. Naturalmente, la fase di precomputazione è computazionalmente costosa, quindi l'attaccante vorrebbe riutilizzare il più possibile qualsiasi gruppo danneggiato. Questo potrebbe essere rilevato tenendo traccia dei gruppi precedenti.

Invece di fare controlli per i gruppi ricorrenti, il semplice calcolo dei propri parametri è probabilmente più semplice. L'utilizzo di parametri DH generati da altri, senza garanzie niente-up-sleeves , richiede una certa fiducia nell'entità che fornisce quei nuovi gruppi, indipendentemente dal fatto che i primi siano sicuri o meno.

score 0 · Answer 2

A parte i rischi che i parametri DH dei gruppi potrebbero potenzialmente essere manipolati, questo non ha senso se si valutano i costi per un utente malintenzionato.

Se si presume che qualcuno con molta potenza di calcolo bersagli direttamente il proprio servizio, si spera che non si utilizzino i parametri appena scaricati da qualche parte.

Se temi un targeting meno specifico, come la NSA probabilmente non ti bersagliano, ma se non è troppo costoso per controllare il tuo traffico, potrebbero sembrare solo per essere sicuri di non essere ~~Commu~~ Terrorista, quindi questo aumenterebbe il rischio. Se generi parametri solo tu usi, possono solo curiosare i tuoi dati. Se utilizzi parametri utilizzati da 10.000 persone perché li cambiano automaticamente ogni settimana, hai appena infranto questi parametri 10000 volte più degni di un attacco .

Quindi, se si presuppone che x le persone utilizzino i parametri modificati settimanalmente, l'incentivo per qualcuno a romperli equivale a interrompere i parametri che si utilizzano ma a cambiare solo ogni x settimane.

Quindi usa semplicemente i tuoi parametri personali e cambiali non settimanalmente.