No estoy seguro de si esto es posible, pero quiero poder comenzar con una cadena, y luego averiguar cuál es la entrada que debe estar en el crypt para obtener esta cadena.¿Hay alguna manera de revertir una cripta() en c?
O tal vez es imposible, ¿cuál sería el objetivo de todos modos?
Sí, hay una sal en el código donde intento esto.
Por intención de diseño, crypt() es un hash de un solo sentido. Como todos han dicho, eso significa que la intención es que sería computacionalmente inviable descubrir una cadena de texto sin formato que produzca el mismo hash.
Un par de factores tienen un efecto en esa intención de diseño.
cálculo es mucho más barato lo que era cuando crypt() fue diseñado. Peor aún, no se anticipó la velocidad a la que el cómputo se hizo más barato, por lo que ahora es mucho más barato de lo que jamás se hubiera imaginado.
DES no se ha retrasado tan bien como se pensaba. Sin embargo, fue probablemente la mejor opción dada la situación de conocimiento público en ese momento.
Incluso si el cálculo aún no es lo suficientemente barato como para hacer su propio craqueo, la nube que es Internet ya ha hecho un gran trabajo por usted. La gente ha estado computando y publicando Rainbow Tables que permiten atajar gran parte del cálculo requerido para revertir un hash en particular. (Jeff had a blog post on rainbow tables too). Salt ayuda a proteger contra tablas de arcoíris (porque necesitaría un conjunto de tablas para cada valor posible de la sal), pero el tamaño de la sal utilizada en la implementación clásica de crypt() es de solo 12 bits, por lo que no es tan enorme bloque como se podría esperar.
Peor aún, para ciertas funciones de alto valor de hash (como el LM hash inventado para las contraseñas antiguas Microsoft LAN Manager sino que se utiliza para abreviar contraseña en todas las versiones de Windows antes de Vista) diccionarios casi completos de los hashes y sus inversos existe .
No .. es una función de una sola vía.
No.
crypt() no es un algoritmo reversible (que utiliza una función unidireccional), que se hace más difícil a la fuerza bruta por la adición de sal al valor cifrado.
Editado por comentarios.
La sal no es lo que la hace irreversible. "Sal" es lo que hace que sea más difícil usar un algoritmo separado con una búsqueda exhaustiva de tablas para encontrar el inverso para un subconjunto de su rango. –
No, esa es la idea detrás de las funciones hash unidireccionales, pero puede usar google para ayudarlo en algunos casos.
Para responder a un comentario a esta respuesta (google no ayudará si hay un comentario), respondo: sí y no. La sal aumenta el espacio de las soluciones, haciendo que la creación de un diccionario completo sea menos fácil (porque para cada palabra debe calcular y almacenar una versión encriptada para cada posible sal de dos letras). Si usted supone que Internet es una base de datos gigante y su índice es de Google, lo que Google hace es buscar si hay algún lugar donde aparezca la cadena cifrada en la web. La presencia de sal reduce la posibilidad de que la encuentre, pero si tiene la suerte de que la ocurrencia esté presente, y también está junto con el texto claro, entonces tiene la contraseña.
Véase también this article on slashdot.
Concluyendo: la sal reducirá la posibilidad de encontrar esa cadena encriptada específica en la web, cierto, pero Google es indiferente a cualquier cantidad de sal, y aún puede ayudar de alguna manera si tiene suerte (como era para el caso que dí).
Google no ayudará si hay sal. – Brian
No, no es posible echar un vistazo a este sitio (suponiendo que está utilizando la biblioteca de C de GNU) http://www.gnu.org/s/libc/manual/html_node/crypt.html
La forma en que la cripta se sala será casi garantizar que lo que estamos tratando de hacer ISN' va a funcionar
La sal no tiene nada que ver con que el algoritmo sea reversible o no. La sal está allí para proteger contra los ataques de búsqueda de tablas del arco iris. –
Esa función es unidireccional es la columna vertebral de todos los esquemas de contraseñas en el mundo. Si alguien aquí respondiera "sí, y así es como ...", el gobierno se vería obligado a eliminar de inmediato sus comentarios, ir a quemar su casa y llevarlos a un lugar no revelado.
En resumen, no.
nah, pierden datos confidenciales en las computadoras portátiles todos los días. ¿Crees que realmente les importa si descifras un hachís obsoleto? ;) Por supuesto, si descifra el último DRM de Britney Spears en su lugar, prepare su equipaje para unas vacaciones en guantánamo :) –
crypt() se basa en el algoritmo md5 o des-based (remitiéndose a http://www.gnu.org /s/libc/manual/html_node/crypt.html). Md5 es bien conocido por NO ser lo suficientemente efectivo, y en cuanto a des, los viejos algoritmos tampoco son efectivos, hay muchas versiones nuevas, no creo que ningún gobierno use exactamente esta implementación como su columna vertebral para hash (especialmente, que la NSA que es responsable de DES ha creado un algoritmo basado en SHA como reemplazo). –
Para ambos: Md5 se considera "obsoleto" porque ya no usa suficientes bits para sobrevivir a los ataques de fuerza bute, no porque el algoritmo tenga problemas. Si pudieras descubrir cómo invertir el algoritmo, podrás descifrar * cualquier * cripta (sin importar el tamaño del bit) que use el mismo método matemático. Las contraseñas y las comunicaciones encriptadas en todo el mundo podrían estar abiertas para usted. –
Si se trata de una implementación anterior de crypt(3), utilizando DES, entonces casi (pero no del todo) fuerza bruta.
En ese esquema, la entrada se trunca a 8 caracteres, y cada carácter a 7 bits, lo que significa que hay un espacio de 56 bits de contraseñas distintas para buscar.
Para DES solo, puede buscar todo el espacio en aproximadamente 18 días en FPGA de $ 10K (http://en.wikipedia.org/wiki/Data_Encryption_Standard#Brute_force_attack), por lo que el tiempo esperado es de 9 días. Pero asumo que no tienes $ 10K para gastar en el problema. Dale unos años más, y quién sabe si los crackers de DES correrán en tiempo plausible en la GPU de una PC.
Incluso entonces, crypt(3) tradicionalmente implica 25 rondas de DES, con ligeras modificaciones al algoritmo basado en la sal, por lo que esperaría que fuera al menos 25 veces más lento que la fuerza bruta.
Las implementaciones más recientes de crypt(3) están más allá de la fuerza bruta, ya que están basadas en mejores algoritmos hash que las basadas en DES que el antiguo crypt(3) utilizó.
Por supuesto, si la cadena no es aleatoria (por ejemplo, si se trata de una contraseña elegida por un humano), entonces es posible que pueda obtener un tiempo mucho mejor esperado que la fuerza bruta.
Por cierto, acabo de hacer una prueba de juguete, y mi craptor de cripta "más simple posible" tomaría unos 300,000 años para cubrir el espacio clave usando un núcleo de mi computadora portátil. '-lcrypt' con gcc me está dando la versión de cripta de 8 bits x 7 bits. Entonces eso no es fácil de descifrar, pero tampoco es seguro suponer que alguien no puede descifrarlo. –
sí se llama crackear contraseña http://en.wikipedia.org/wiki/Password_cracking – newacct