Yo te sugeriría el corte inglés... claro siempre y cuando el precio de lo que vayas a comprar, no resulte elevado. En informática suele haber cosas caras y 'normales', gangas ya sabes que no vas a encontrar...

https://www.elcorteingles.es/ayuda/como-pagar/

Hacen financiación con su propia entidad...
Aparte como te señalaba un compañero más arriba con tu tarjeta de crédito o débito, podrías hacerlo. Ellos cobran la totalidad y el banco te va cobrando mes a mes, en este caso es el banco quien te cobra los intereses. ante las dudas acude al banco e infórmate de si tu tarjeta actual te lo permite, o si necesitas otra... en tal caso asegúrate también que la cuota de una nueva tarjeta no sea excesiva.

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í, exactamente... eso es bueno, pero para entender lo que digo, te refiero a la primera línea de mi mensaje:

Es claro, que si la memoria puede mantener datos incluso sin corriente... entonces no sería distinto de un disco duro, donde en una zona hay algún virus acechante o algún software espaindo... Y sí ya es difícil controlar la seguridad sobre un disco duro, imágina si además puede apoyarse con la memoria.

Tratra de imaginas un simple ladrón... es cuestión de que le cojan o no...
Ahora trata de imaginar que es ladrón además es policía, o que tiene un compinche que es policía... simplemente puede tapar al ladrón, "perseguirlo" pero no alcanzarlo (hacer el paripé de perseguirlo), más aún puede contribuir aportando datos más específicos, incluso puede siendo atrapado, puede abrirle la puerta para que escape... las posibilidades para el ladrón aumentan considerablemente. Es lo mismo si a nivel hardwarte, los soportes de almacenamiento, cuentan con la inestimable ayuda de una memoria que también almacena datos... Exigiría instalar programas, que nada más arrancar el equipo limpie la memoria, para asegurarse que no hayas un virus, pero igualmente ese programa sería hackequeable, luego no tendríamos seguridad.
Una parte buena también tiene... la hibernación (esto es, encendido y apagado) sería instantáneo, no haría falta 'guardarlo' a disco. en contra con esto mismo, un error que cuelga el sistema (el típico Blue Screen Of Death), sería un proiblema de C0J0N3X, porque reinicias y la memoria seguiría ahí corrupta...

En fin, me parece bien que las memorias requieran menos procesos de refresco, por supuesto ahorra energía y gana velocidad (habrá menos interrupciones hardware segurísimo), pero nunca tanto que conlleve a la pervivencia de la memoria tras el fallo sel suministro eléctrico. Esto nos daría más problemas de cabeza.
Imagina incluso una memoria que mantiene sus datos sin refresco (pongamos 10 segundos) durante varios segundos, sería una puerta llena de posibilidad a explotar contra la seguridad... preguntas del tipo: ¿borré los arrays de claves que usé en mi programa, antes de finalizar el programa pero es seguro, que los datos están borrados, o podrían aún ser rescatados, aunque solo sea haciendo un volcado de la memoria y luego con calma proceder a una búsqueda?.
No hay que olvidar que una memoria persistente (por ejemplo usando algún campo magnético), puede conservar estados transitorios que sirven para conocer que dato existía ahí antes del actual... luego el orrado de memoria, no sería 100%efectivo. Y desde luego no tenemos ninguna garantía de que un fabricante haga esto bien, o a propósito deje ventanas abiertas a estas posibilidades.

Resumiendo es un "Nuevo Mundo" de posibilidades y problemas de seguridad que añadir a los actuales. Mientras, el usuario UNIVERSAL (el doméstico, tu, yo cualquiera) no notará grandes beneficios reales y tangibles, pero los problemas potencialmente serían significativos y más al correr del tiempo y los "Badkers" empiecen a enteder el profundo socavón que se guarda ahí y empiecen a idear soluciones para penetrar...

Cuantas tonterías tenemos que oir. Puedo entenderlo de los 'autores' que son unos agonías que siempre quieren más y más... pero que uno deba oirlo de boca de jueces, ya es para patearlos...

...es que por la misma regla del tres, un vehículo como tal, se vende y el dueño que lo compra puede hacer cosas legales con él, pero también ilegales, ¿entonces... qué?.

¿¿¿¿¿¿Declaramos que los vendedores/fabricantes de coches y vendedores/fabricantes de cuchillos (etc, ab-aeternum), cometen un delito... tal y como se persigue a ese señor que vende televisiones para ver 'contenido' (sea contenido legal o ilegal) ??????????????????

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...

Por supuesto... y ayudaríqa también a ocultar más virus y más intrusiones...

La RAM, volátil, please... basta que consuma menos.
Me da igual si permanece no volátil durante 1-5 segundos, pero que cuando se le retire el suministro eléctrico, y pasen esos segundos, se pierda su contenido por completo.

Entiendo lo que dice, de "para alguna duda tonta"... peor al ser así, algo irrelevante, la gente se aburrirá, porque así no se aprende, entonces habrñás dos grandes y únicos grupos: "Los pavos" que preguntan chorradas y "el otro" cansado de intentar hacerse entender y ver que fracasa, porque no hay una base mínima a la que los pavos puedan agarrarse y entenderlo bien...

Aparte estoy de acuerdo en todos los problemas susodichos... este foro llevas activo varios años, cualquier de cualquier parte del mundo, puede buscar un tema por la red, y aparecerle este foro, puede consultarse después de años, por cualquiera en cualquier parte del mundo... en whatsapp, cómo dices que se puede buscar algo, quién y cuánto tiempo atrás???.

Todavía si lo que pidieras es llevar el foro al móvil, una versión adaptable a la pantalla tendría un sentido muy razonable, aunque supongo que tiene versión móvil (no he trasteado por todas las ramas del foro, aún).

Pero adelante con tu proyecto, yo te animo, quien sabe, quizás tengas en tu mente una forma muy concreta y clara de llevarlo y dé sus frutos... y si no, pués nada aquí seguirá el foro...

Quién sabe... a lo mejor, el antivirus es efectivo y todo, y ha acertado de pleno, señalando ficheros que efectivamente son virus... 

Como para no usar alias... 

Es curioso como empresas como Google, se emperran en que registres tu nombre, teléfoono, domicilio... cuando sus servicios se remiten a algo menos que el camarero de un bar, el trato desde luego no es presencial y siempre será por software, ergo qué importancia tiene que lo solicite un programa por mi...

Ya veremos por donde continúa la batalla de la seguridad, si por el anonimato absoluto o por el registro absoluto. Yo opto por el primero...

El problema de los S.O. en espacila de win2, es que una versión remplaza por completo a otra, es decir en realidad se trata de otro sistema operativo con el mismo nombre, donde a menudo lo que si valen son otros programas (secundarios).
Para mi (y creo que para todo el mundo sensato), una versión, debería ser única y exclusivamente una mejora de lo ya existente y vale que creen algo nuevo, pero jamás la destrucción de algo existente (salvo que se demuestre dañino) o la incompatibilidad con lo existente.


Imaginaros que los fabricantes de aparatos eléctricos, sacaran su nueva versión de enchufes, interruptores... cada pocos años deberñíamos comprar nuevas lavadoras, cocinas, neveras, microondas, aspiradoras, etc... porque sus clavijas serían incompatibles con las 'nuevas'... y ahora imagnemos que lo msimo lo llevaos a todos los terrenos... entonces cad apocos años tendríamos que tirar la casa por completo, poque una actualización de las leyes (versión 3.45.112), diría que las ventanas deben estar a 1.08 cm. de alto, ni mas ni menos, así que obras al canto...

Es normal, que cuando haya que gastarse una cantidad enorme se desista, de hacerlo, después de todo, Mocosoft, cuandosacó el win95, creo recordar que dijo de él que le daban una vida de 20 años, así que apenas si se ha cumplido, y para el win98, le faltaría aún algo...

Yo aún tengo un Commodore vic-20 del año 81, que funciona (36 años ya)... falta ver si los equipos de hoy día (este año) funcionarán dentro de 36 años... en 2053. Con el paso del tiempo, la fiabilidad ha caído y la obsolecencia exige cada vez una vida más corta de los aparatos... basta mirar los móviles...