John el Destripador cada vez más lento

2

He escrito mi propio módulo de John the Ripper y al menos está funcionando. Lamentablemente, no me gusta mucho el análisis de rendimiento de John the Ripper, así que simplemente lo inicié con una contraseña más o menos inseparable para ver algunos números.

El hash está salado.

Pero ahora el estado es un poco extraño para mí. Comienza con:

0g 0:00:00:02 0g/s 140413p/s 140413c/s 140413C/s

Pero luego se vuelve más lento con el tiempo. Después de una hora está en:

0g 0:00:52:12  3/3 0g/s 1383p/s 154053c/s 154053C/s

Y después de otra hora está en:

0g 0:02:13:13  3/3 0g/s 849.0p/s 154635c/s 154635C/s

Después de 4 horas, detuve la sesión con una velocidad de

0g 0:04:30:43  3/3 0g/s 673.7p/s 154666c/s 154666C/s

¿Puede alguien decirme qué podría causar esa pérdida en el rendimiento? ¿Y por qué solo los candidatos / segundo se vuelven más lentos mientras que las criptas / segundo y la combinación de la contraseña del candidato y el hash objetivo por segundo siguen siendo tan rápidos como antes?

Ahora encontré otro problema para agregar a la pérdida de rendimiento. Digamos que tengo 24 hashes con 24 sales diferentes. Uno de ellos tiene la contraseña test123. Si este hash está por debajo de los últimos 5 todo funciona perfectamente. Pero si está en los primeros 5 no se resquebrajará (al menos no en la segunda fase de la llamada de John predeterminada). Realmente no tengo idea de lo que podría causar este error. Si mi archivo es más pequeño (5 hashes), no encuentra este error y puede romper el hash sin importar dónde esté. (Según algunas pruebas que hice, parece que esto podría deberse a la diferente longitud de los hashes ... Todavía no estoy seguro de que todavía esté haciendo pruebas)

Editar:

He probado algunas cosas y, como nadie ha respondido todavía, solo modificaré la pregunta:

La pérdida de rendimiento que experimenté anteriormente es solo si tomo archivos grandes (310 hashes para el ejemplo anterior)

Ahora, si tomo un archivo más pequeño (6 hashes), el rendimiento es más estable o incluso parece aumentar. Algunos números:

1g 0:00:00:06  3/3 0.1430g/s 33762p/s 136944c/s 136944C/s sheble

y después de una hora:

3g 0:00:56:56  3/3 0.000877g/s 41042p/s 156740c/s 156740C/s luecdt

La estructura de los archivos es siempre la misma. La longitud de los hashes fue la misma también esta vez después de haber encontrado el error mencionado anteriormente. Pero todavía tengo la pérdida de rendimiento con archivos grandes.

Ya he comprobado con Valgrind si hay alguna pérdida de memoria o algo, pero no surgió nada. El uso de RAM también se mantiene constante durante 17 horas.

    
pregunta Thanathan 21.09.2015 - 15:58
fuente

0 respuestas

Lea otras preguntas en las etiquetas