Bueno, yo separé en efecto la parte de generar las permutaciones del hecho de escribirlo a fichero.
De hecho es ineficiente (e inútil, si el propósito no es otro que probarlo) escribirlo a fichero... siempre sería preferible escribir una API, a la que se pueda llamar y pedir generar (por ejemplo), 1millón de claves a partir de la siguiente (recibida) y que entregue el array por referencia en memoria... Hablamos de que la idea final, sería lógicamente usar las claves en algún programa. Por tanto el coste de escribir a fichero, leer de fichero y espacio ocupado es nulo. Esto sólo debería hacerse con propósitos de prueba... supongo que me tniende sperfectamente.


Tengo varias versiones, ya que me fascina idear soluciones diferentes para un mismo problema. Pero te hablaré de dos versiones básicas... bueno 3...

--------------------------------------
A - En esta la idea básica es la simplicidad del algoritmo.
Y en ella se genera cada clave por completo, simplemente convirtiendo un número decimal (base numérica 10) en la base numérica x, siendo x el tamaño del diccionario (pongamos 26, si el alfabeto fuere por ejemplo A-Z). Es decir esta es la misma que tu has descrito más arriba y que veo en el código...


--------------------------------------
B - En esta otra, la idea básica es buscar velocidad, por supuesto tampoco debe ser muy complejo, ya que sino queda reñido también con la velocidad´.
Así la complejidad subyace sólo en la dificultad de enteder el algoritmo (a pelo, si no se dieran explicaciones).
Entonces para el caso, ni se genera un array de claves. Es la forma más eficiente para usarlo en el propio programa (destinado a probar las claves 'donde fuere').
Esto es, se genera una sola clave y es esa misma la que se va modificando. Ya que en efecto, la diferencia entre una clave y la siguiente solo es (casi siempre) 1 sólo carácter es superfluo generar de nuevo el resto de caracteres de la clave. Por lo tanto generar la nueva clave, cambia casi siempre 1 sólo carácter, lo que dispara la velocidad de cálculo respecto del anterior por 6 (para un tamaño de clave de 6)... algo más al tener en cuenta que tampoco lo almacenamos en un array de claves, aunque por simplicidad en vez de tomarlo como string, es un array de bytes/chars.

-----------------------------------------------------
C - El tercer algoritmo, es más simplificado aún y más veloz que cualquiera de los otros. En realidad usa cualquiera previo, pero éste está diseñado para claves muy largas...
La idea básica es que: 4+4=8: 4+3=7; 5+4=9, o 6+6=12...
Pongamos el caso de una clave de largo 8 caracteres... Luego si generamos pongamos un array para las claves de 4 caracteres (26^4= 456.976) tan sólo algo menos de medio millón, esto se puede generar en apenas una décima de segundo...

Así el paso 1º de este algoritmo es llamar a otro algoritmo, para que genere un array de claves manejable.
El segundo paso, es doble bucle, en ambos se usa el array generado, y la clave generada no se almacena como array (26^8= unos 208mil millones), tal como pasa en el algoritmo B, es para velocidad.
Este doble bucle, simplemente concatena las dos partes actuales.
Como se ve en este tercer algoritmo, generar una clave, se reduce a concatenar dos medias partes. Puede optimizarse mucho, si se usan funciones de copia de memoria, también evitando la creacción y destrucción de strings, o arrays...
Así ClaveActual debería ser una instancia que se crea una sola vez en todo el algoritmo y que se reutiliza una y otra vez. De hecho podemos ver que si ArrayClaves tiene un tamaño de medio millón (500.000), entonces claramente se veque en el bucle interno, siempre estamos concatenando (copiando ClaveExt, a pesar de que sabemos que no va a variar en el próximo medio millón de veces),

Entonces una varicación mejorada del algoritmo sería:

Es decir ahora hacemos una concatenación diferida en dos veces...

Otra variación si hacemos una API, que debiera entregar un array de claves de tamaño 8, conllevaría generar el array de claves de solo 4 caracteres, en claves de tamaño 8, dejando así hueco 4 caracteres (a derecha por ejemplo, y que son reutilizados en cada ciclo del bucle Interno), para rellenar en este doble bucle, y donde el bucle interno, sería una adaptación del algoritmo "B" (o sea encajarlo aquí, para hacer la variación de 1 sólo carácter en cada ciclo para generar una clave, en vez de copiar en cada cuiclo los x caracteres de la derecha.

Este algoritmo "C", tien su complejidad, sólo en la forma de adaptación, para hacerlo versátil y que pueda por tanto generar claves de tamaño X, partiendo siempre de la generación de arrays de largo 2,3,4 y 5, desde 2+2, hasta 5+5 y separado si la clave es mayor de 10, para 3+4+4 hasta 5+5+5, etc....
Es decir separando si se quiere hacer doble bucle, triple, bucle, cuádruple bucle, etc...


----------------------------------
Ahora mismo, no puedo hacer una prueba de velocidad, ya que tengo algunas operaciones calculando y le llevarán parte de la noche (las pruebas no reflejarían el rendimiento real si el procesador está trabajando al 80%), pero mañana, hago las pruebas que me reclamas y al efecto, limpio el código y cambio nombres de variables para facilitar su entendimiento...

(si creo recordar, de memoria, que poco tiempo atrás, quizás un mes o así, probé a generar con un alfabeto de 26 caracteres (A-Z), para un tamaño de clave de 7 caracteres... lo que proporciona algo más de 8 mil millones y tardó prácticamente unos 5 minutos, es decir aprox. 1.600.000.000 claves por minuto. (en un equipo del 2008, y con una versión hecha en VB6, al caso lo reharé en VB-2010, que es lo que tengo en casa). Dado que el algoritmo anunciado como "A", es la idea básica que tu has hecho, y que el algoritmo "C", está suficientemente descrito, pondré el código del algoritmo "B"...

Saludos...

Tengo pendiente mirar lo que hiciste y subiste en GitHub...

Esta mañana antes de marcharme al trabao, hice la prueba y tardaba solo 187segundos, básicamente eleva a 2.666millones de claves por segundo...

Y sí, es sin escribir claves a disco. Ya he mencionado, que es estéril guardar un diccionario a disco, el tiempo necesario para ello es gigantesco comparado con el cálculo, además del espacio gigante que requieren. Cuando se precisa usar un diccionario, y más tarde se interrumpe, basta guardar la secuencia actual (última usada) y luego es relativamente fácil volver a ese punto y continuar. Esto hace inútil tener que requerir un diccionario en disco (un diccionario gigantesco, tampoco pasa nada por tener alguno de unos pocos cientos de Mb.)

Es común ver a alguien 'presumir' de tener un diccionario de nosecuantos GB. Yo cuando oigo decir eso, me apena, por que de lo que está presumiendo (sin saberlo) es de ignorancia.

Los dicionarios en fichero tienen un uso muy restringido, mejor dicho, si quien lo hace lo entiende debería saber que su uso debe restringirse a probar la validez del algoritmo y a casos como: "Diccionarios con las 10.000 claves más usadas en internet.txt", "dicionarios con las claves por defecto de los router 1990-2020.txt", etc... es decir donde no existe una secuencia combinatoria, sino que directamente son conocidas y 'misteriosamente' siguen siendo útiles...

No te preocupes, el código entre VB y C es apenas insignificante, de todos modos con los comentarios que adjunte, podrás entenderlo sin problemas y migrarlo a tu propio código...

Sí, saco por pantalla los resultados. Cuando creo o modifico un algoritmo, lo que hago es volcar parcialmente a un listbox para verificar que está operando correctamente. Estando seguro de que funciona bien, deja de ser necesario visualizarlo.

Yo de tí (ya que te has tomado la molestia de hacr toda la operatoria para volcar a fichero), lo dejaría opcional y limitando la cantidad... por ejemplo, para un tamaño de clave de hasta 5 caracteres, y si las claves son más largas, limitarlas a x millones de claves a partir del intérvalo que el usuario decida... así si prefiere volcarlo todo a fichero es cosa suya, y la pérdida de tiempo que experimente será decisión suya propia.

--------------------------
Ahora me pongo a pasarlo a VB-2010, no usaré ningún método que resulte extraño, ni palabras clave que hagan inentendible a alguien que no conozca el entorno de Visual Studio... aunque seguramente me extienda en facilidades (generalmente superfluas, pero que siempre se agradecen).

Yo no me planteo guardarlos a disco. Algún diccionario con claves de 3-5 caracteres, y sólo para verificar que es correcto, es más que suficiente. Ya no te cuento, lo lento que sería sobre un disco duro...
Es estupendo... Seguramente puedas mejorarlo más, al menos la parte de generar las claves (que es en la que yo me centro y la que me importa... no veo práctico escribir a disco diccionarios muy grandes ni tampoco pretender usarlos (desde fichero) en algún programa, para tratar por fuerza bruta romper una contraseña).

Me falta por pasar un ejemplo con el tercer método que te explicaba, a ver si esta noche tengo un tiempito y puedo pasarlo y lo subo mañana...

Con las pruebas que he hecho, hasta el momento, para el 2 método, obtengo los siguientes resultados (las pruebas siempre sobre un diccionario completo de claves de 7 caracteres (el alfabeto de ejemplo, siempre es A-Z)), es decir: 8.031.810.176 claves:
- Implementado con bucles FOR: 53 segundos.
Esta implementación adolece de varios problemas y una ventaja:La ventaja es que permite operar con claves desde 1 hasta 16 caracteres.
Los problemas: Los bucles FOR, siempre son más lentos (especialmente cuando están anidados, para uno solo no importa demasiado). Es complejo establecer un punto inicial, de hecho aquí se considera como inicio siempre la clave más baja.

- Implementado con clases de modo recursivo: 155 segundos.
Esta implementación tiene la particularidad de que el código es más 'elegante'. enseña algo que mucha gente quizás no emplee o del que tenga nula noción; usar clases de forma recursiva (tal y como se haría con una función). Permite establecer de forma sencilla el estado inicial de comienzo (en cualquier clave deseada). En contra es más lento, fruto de la recursividad frente a la iteración. Otra ventaja es que el código es muy escueto.
Esta implementación no está limitado a un tamaño de clave, podría perfectamente señalarse una clave de 5000 caracteres, sin otro problema que el tiempo de procesado... (sin tener que cambiar absolutamente nada en el código, ni problemas de desbordamientos, ni nada).

- Implementado con bucles DO: 35 segundos. esto supone 229'5millones de claves por segundo, ó 13.700 millones de claves por minuto. Ya te adelanto que con el algoritmo3, esta cifra aumenta aún más...
El código es el equivalente al del bucle FOR, pero desde aquí, permite de un modo sencillo establecer el estado inicial (la clave desde la que empezar/continuar enumerando).

Recuerda que los valores siempre son para generar las claves (y teniendo en cuenta lo viejo de mi equipo: 9 años), no para escribir a disco. También hay que señalar que solo se usa un núcleo del procesador, desisto de crear un algoritmo que trabaje en paralelo con más de un núcleo, a fin de cuentas mi propósito no es llegar a usar los diccionarios, sino, solo dejar 'exangüe' al algoritmo generador...

Una particularidad muy interesante en todas estas implementaciónes del algoritmo2, es que cada carácter obtiene su propio alfabeto (de forma indirecta, tal como se explica a continuación)... aunque por defecto uno ponga A-Z, en realidad hay tres parámetros:
Valor minimo, ejemplo: AAAAAA
Valor Máximo, ejemplo: ZZZZZZ
Valor Inicial, ejemplo: GDAXCA

Esto permite que pueda indicar el valor mínimo y máximo de formas distintas, por ejemplo así:
Posiciones:      543210
------------------------------
Valor Minimo:  A0ZD9A
Valor Máximo: ZZAK0Z
Entonces, implica que, tiene definido un alfabeto (en estos casos siempre basado en el ASCII)
El carácter '0': A-Z  ---> 26 caracteres, incremento
El carácter '1': 9-0  ---> 10 caracteres (numéricos), decremento
El carácter '2': D-K ---> 13 caracteres incremento
El carácter '3': Z-A ---> 26 caracteres decremento
El carácter '4': 0-Z ---> 43 caracteres 0-9, 9-A, A-Z (10+7+26 si no he contado mal)
El carácter '5': A-Z ---> 26 caracteres.

La implementación del bucle FOR, no admite el parámetro "Valor Inicial", en los otros dos casos a la entrada garantiza (chequea y corrige), que el caracter en cada posición esté en el rango Min-Max del alfabeto que admite...

Algunos consejos para mejorar la velocidad de escritura a la unida de almacenamiento:

- El buffer siempre debería ser multiplo de 64, de hecho mucho mejor si es múltiplo exacto del tamaño de 1 sector de disco.

- También puedes lograr mejor velocidad de escritura, si desactivas la caché. Dado que solo es 1 única escritura y no lectura, si puedes desactivar (o hay alguna función específica en el lenguaje), que deshabilita la caché del S.O. no pierde tiempo en ello. A veces el S.O. (en win2 al menos), se empeña en hacer uso de la caché, aún cuando tú solo vayas a leer o escribir una única vez (por ejemplo porque vas a hashear uno o varios ficheros).

- Y deberías probar si lo admite la escritura síncrona, la asíncrona a veces conlleva un retraso por defecto. Aunque en un SSD este comportamiento, podría resultar diferente.

- Por último, para aumentar aún un poco la velocidad de escritura, yo te recomendaría que precalcularas el tamaño total en bytes que va a tener el fichero, y generar de antemano el fichero (en win2, esto es tan fácil como escribir el último byte del fichero (basta poner un 0), y actoseguido retornar el puntero de escritura al comienzo del fichero)... entonces se busca el espacio libre de una sola vez y trata de encontrarlo contiguo... si tiene que andar buscando espacio libre a medida que vas escribiendo, se demora más en buscar sectores libres, además es una búsqueda constante para 1 sector más... cuando se sabe el tamaño del fichero, es mejor siempre reservarlo al completo de una sola vez. Así hace una sola búsqueda, y si se da el caso de que ese tamaño existe contiguo, es muy, muy rápido.... si solo se reclama sector a sector, el S.O. te va asignando sectores libres entre medias de otros ficheros, aunque esto último en un SSD no tiene impacto, todavía la búsqueda de sectores libres (uno a uno), sigue teniendo un costo que se reduce notablemente cuando hay espacio suficiente y se le pide por completo, ya qe entonces trata de localizarlo contiguo...