Non sono sicuro se ciò sia possibile ma voglio essere in grado di iniziare con una stringa e quindi capire quale input deve essere inserito in crypt per ottenere questa stringa.C'è un modo per invertire una crypt() in c?
O forse è impossibile, quale sarebbe comunque l'intero scopo della cosa?
Sì, c'è un codice nel codice in cui sto provando questo.
Per intento di progettazione, crypt() è un hash unidirezionale. Come tutti hanno detto, questo significa che l'intento è che sarebbe computazionalmente impossibile scoprire una stringa di testo in chiaro che produca lo stesso hash.
Un paio di fattori influiscono sull'intento di progettazione.
calcolo è un molto più economico di quanto non fosse quando crypt() è stato progettato. Peggio ancora, la velocità con cui il calcolo è diventato più economico non è stata anticipata, quindi è molto più economico ora di quanto si sia mai immaginato potesse essere.
DES non ha retto così come si pensava. Tuttavia, era probabilmente la scelta migliore data allo stato di conoscenza pubblica al momento.
Anche se il calcolo non è ancora abbastanza economico per fare il tuo cracking, il cloud che è Internet ha già fatto molto del lavoro per te. Le persone hanno elaborato e pubblicato Rainbow Tables che rendono possibile la scorciatoia di molti dei calcoli richiesti per invertire un particolare hash. (Jeff had a blog post on rainbow tables too.) Il sale aiuta a proteggere dalle tabelle arcobaleno (perché avresti bisogno di un set di tabelle per ogni possibile valore del sale), ma la dimensione del sale utilizzato nella classica implementazione di crypt() è di soli 12 bit, quindi non è così un enorme blocco come si spera.
Peggio ancora, per determinate funzioni ad alto valore hash (come il LM hash inventata per vecchie password Microsoft LAN Manager ma utilizzato per brevi la password in tutte le versioni di Windows prima di Vista) dizionari quasi completo di hash e loro inverse esistono .
No .. è una funzione unidirezionale.
No.
cripta() non è un algoritmo reversibile (utilizza una funzione unidirezionale) che è reso più difficile forza bruta mediante l'aggiunta di sale al valore crittografato.
Modificato per commenti.
Il sale non è ciò che lo rende irreversibile. "Salt" è ciò che rende più difficile l'utilizzo di un algoritmo separato con una ricerca esauriente della tabella per trovare l'inverso per un sottoinsieme del suo intervallo. –
No, questa è l'idea alla base delle funzioni hash unidirezionali, ma in alcuni casi è possibile utilizzare google.
Per rispondere a un commento a questa risposta (google non aiuterà se c'è un sale) Io dico: sì e no. Il sale aumenta lo spazio delle soluzioni, rendendo meno facile la creazione di un dizionario completo (poiché per ogni parola è necessario calcolare e archiviare una versione criptata per ogni possibile sale a due lettere). Se si presuppone che Internet sia un database gigante e google il suo indice, ciò che Google fa è cercare se c'è da qualche parte l'occorrenza della stringa crittografata nel web. La presenza di sale riduce la possibilità che tu la trovi, ma se sei abbastanza fortunato che l'evento è presente, ed è anche insieme al testo in chiaro, allora hai la password.
Vedere anche this article on slashdot.
Concludendo: il sale ridurrà la possibilità di trovare quella stringa crittografata specifica intorno sul web, è vero, ma Google è indifferente a qualsiasi quantità di sale, e può ancora aiutare in qualche modo, se vi capita di essere fortunati (come è stato per il caso che ho dato).
Google non aiuterà se c'è un sale. – Brian
No, non è possibile dare un'occhiata a questo sito (supponendo che si sta utilizzando la libreria GNU C) http://www.gnu.org/s/libc/manual/html_node/crypt.html
Il modo in cui la cripta è salato sarà praticamente garanzia che quello che stai cercando di fare isn' andando a lavorare.
Il sale non ha nulla a che fare con l'algoritmo che è reversibile o meno. Il sale è lì per proteggere dagli attacchi di ricerca di tavoli arcobaleno. –
Questa funzione essendo a senso unico è la spina dorsale di ogni schema di password nel mondo. Se qualcuno qui dovesse rispondere "sì, ed ecco come ..", il governo sarebbe costretto a cancellare immediatamente il loro commento, andare a bruciare la loro casa e portarli via in una località nascosta.
In breve, no.
nah, perdono dati riservati sui laptop ogni giorno. Pensi davvero che ti importino se crei un hash unidirezionale obsoleto? ;) Naturalmente, se crei l'ultimo DRM di Britney Spears invece, prepara il tuo bagaglio per una vacanza a Guantanamo :) –
crypt() si basa sull'algoritmo md5 o des-based (facendo riferimento a http://www.gnu.org) /s/libc/manual/html_node/crypt.html). Md5 è ben noto per NON essere abbastanza efficace, e come per il des, anche le vecchie des algorihms sono inefficaci, ci sono molte nuove versioni, non credo che nessun governo utilizzerebbe esattamente questa implementazione come la loro spina dorsale per l'hashing (in particolare, l'NSA responsabile per DES ha creato un algoritmo basato su SHA come sostituzione). –
Per entrambi: Md5 è considerato "obsoleto" perché non utilizza abbastanza bit per sopravvivere più agli attacchi bute-force, non perché l'algoritmo ha problemi. Se si riuscisse a capire come invertire l'algoritmo, si sarebbe in grado di crackare * any * crypt (indipendentemente dalla dimensione del bit) che utilizza lo stesso metodo matematico. Le password e le comunicazioni crittografate in tutto il mondo potrebbero essere aperte a te. –
Se si tratta di una vecchia implementazione di crypt(3), utilizzando DES, è possibile (ma non abbastanza) forzare la forza.
In tale schema, l'input viene troncato a 8 caratteri e ogni carattere a 7 bit, il che significa che c'è uno spazio di 56 bit di password distinte da cercare.
Per il solo DES, è possibile cercare l'intero spazio in circa 18 giorni su FPGA da $ 10.000 (http://en.wikipedia.org/wiki/Data_Encryption_Standard#Brute_force_attack), quindi il tempo previsto è di 9 giorni. Ma suppongo che tu non abbia $ 10K da spendere per il problema. Dagli ancora qualche anno e chissà se i cracker del DES funzioneranno in un tempo plausibile sulla GPU di un PC.
Anche in questo caso, crypt(3) prevede tradizionalmente 25 round di DES, con lievi modifiche all'algoritmo basato sul sale, quindi ci si aspetterebbe che sia almeno 25 volte più lento alla forza bruta.
Le implementazioni più recenti di crypt(3) sono ben al di là della forza bruta, poiché si basano su algoritmi di hash migliori rispetto a quello basato su DES utilizzato dal vecchio crypt(3).
Ovviamente, se la stringa non è casuale (ad esempio se si tratta di una password scelta da un essere umano), potrebbe essere possibile ottenere un tempo previsto migliore rispetto alla forza bruta.
Btw, ho appena fatto un test sui giocattoli, e il mio cracker di cripte "il più semplice possibile" impiegherebbe circa 300.000 anni per coprire lo spazio chiave usando un nucleo del mio laptop. '-lcrypt' con gcc mi sta dando la versione 8char x 7 bit di crypt. Quindi non è crackabile da parte mia, ma anche non sicuro di presumere che non sia crackabile da qualcuno. –
sì si chiama password cracking http://en.wikipedia.org/wiki/Password_cracking – newacct