Foro de elhacker.net

Quiero reorganizar un texto en base a la posición alfabética de cada caracter de otro texto programáticamente.

Tengo un array que contiene caracteres random:
array1 = ["H", "o", "l", "a", " "];

Y otro array que contiene el mismo número de caracteres:
array2 = ["a", "d", "m", "i", "n"];

En base al array2 quiero ordenar el array1 de la siguiente forma:

array2 = ["1", "4", "13", "9", "14"]

a = primeraPosicion
d = segundaPosicion
m = cuartaPosicion
i = terceraPosicion
m = quintaPosicion

ResultadoQueQuiero = ["H", "o", "a", "l", " "];

No consigo implementarlo.

Me entreveré mucho, sorry, creo que es así:

Una vez obtenido esto
array2 = ["1", "4", "13", "9", "14"]
hacemos:
Repites eso 4 o 5 veces, aunque cada vez se requieren menos ifs.

Hacerlo prolijo y usando sólo 1 repetición o 2, te lo dejo a ti xD

primero reduce los numeros a su minima expresion organizativa... es decir


la forma mas simple de hacer eso es organizar el array de manor a mayor y luego ver en que posicion estan ubicados en el original...

luego simplemente ubicar en relacion al segundo array (la letra en

• va en
• , la letra en [1] a [1], la letra en [2] va a [3]... etc)

Muchas gracias, lo implementé de esta forma que me pareció sencilla. Lo implementé en js de forma un poco cutre jaja. Ya lo mejoraré:

function SMOA(TextCif, Contrasenha)
{
var temp = "";
var temp2 = 0;
var ct = Contrasenha.length;
 
    for(var j = 0;  j < TextCif.length; ++j)
   {
      for(var i = 0;  i < TextCif.length-1; ++i)
      {
       temp2 = i;
       ++temp2;
         if ( temp2 < ct || temp2 == ct)
         { 
            if (Contrasenha[i] > Contrasenha[temp2])
            {
            temp += TextCif[temp2];          
            TextCif[temp2]=TextCif[i];            
            TextCif[i]=temp[0];
            temp = ""; 
            }   
         }     
      } 
   } 
return TextCif;
}

Estaba intentando implementarlo como dices engel lex antes de crear el tema en el foro pero me quedaba mucho código y un batiburrillo.

Es parte de una librería sencilla en javascript que estoy creando con un cifrado que quiero que sea irrompible basándome en el principio de que todas las posibilidades son igual de frecuentes estadísticamente.

Por ejemplo "hola que tal" 12 caracteres dara un resultado que al intentar romperlo dará todas las combinaciones posibles de caracteres de 12 caracteres. Es decir, el texto original podría ser:
"aaaaaaaaaaaa" o "qbfkwusbwp1;$" o "adios amigos", etc.

Ahora estoy mirando de que forma fixear el tamaño a un tamaño concreto sin limitar la cantidad de entrada sin rompear la equidad estadística.

Los cifrados actuales basan su seguridad en capacidad de cómputo, y no me convence ya que teóricamente todos puede romperse dada X capacidad de cómputo e Y tiempo.

de haber dicho en js :P es corto...

var original = ["H", "o", "l", "a", " "];
var orden = ["a", "d", "m", "i", "n"];
var copia = orden.slice(); 
copia.sort();
 
var salida = [];
 
copia.forEach(function(item){
  salida.push(original[orden.indexOf(item)] ) 
})
 
 
 
 

St..Man... Eso es implementar una tabla indexado por otra.

Sea el ASCII. que como sabes va de 0 a 255 (que se supone es el punto de partida), donde (por ejemplo) la 'A' ocupa la posiciópn 65, pero en tu caso ocuparía la posición 0...

MiTabla(0) = ASCII(65)
igual para el resto...

Si van contíguos, podría usarse un bucle, por ejemplo supuesto el caso de una tabla con las 26 mayúsculas:

Ahora 'Mitabla(7)' tendrá la 8ª letra, osea la 'H', el valor 72.
Posteriormente puede usarse en la forma: ASCII(Mitabla(7))

Tengo que probar este código, el que implementé yo no me sirvetras hacer unos cambios.

Esto es una tabla de equivalencias. Yo lo que quiero es desordernar en base al contenido de un array. No tiene nada que ver.

Tiene todo que ver... si cada valor en el array tiene siempre la misma equivalencia en el otro (perdona pero la explicación dada al comienzo es demasiado parca, como para terminar de entender su propósito).

Y si es siempre cambiante, o debe serlo, entonces usa el algoritmo de Fisher-Yates que es esa precisamente su funcionalidad.

Ese algoritmo de barajado utiliza un algoritmo aleatorio asique no puedo reversarlo. En caso de ser un algoritmo pseudoaleatorio no es un CSRNG y podría reversarse y romperse el cifrado.
 Yo necesito desordenar en base a la contraseña para reducir los resultados estadísticos de análisis de frecuencia. Se da por hecho que el atacante no conoce la contraseña. Quiero desordenar antes de pasarle vector de inicialización. También tengo que fixear el tamaño a tamaño fijo. Mejorar la implementación, quitar código inútil, ampliar el diccionario de input y cambiar los caracteres de output para que no necesite base64.
Cifrado Live (http://stringmanolo.byethost12.com/example.html)
Si se os ocurre algo mejor comentarlo.

te recomiendo leer sobre como funcinoa rijandel (la base de aes) para no tener que depender de aleatorios... especialmente de aleatorios de "alto nivel"

No le veo mucho sentido hashear la password. Para eso cifro directamente con aes y no creo un cifrado.
No quiero que mi cifrado dependa de algoritmos que dada X potencia se puedan romper.

todo algoritmo depende de que X potencia lo puede romper XD es imposible hacerlo infinito a menos que tengas una contraseña infinita con data infinita XD por otro lado al hash ser mas largo que la contraseña no es sensible a colision (eso se hace en aes)... por otro lado, para nada es malo el proceso de expasion de contraseña, es base en cualqueir procedimiento decente para evitar el ataque estadistico

por otro lado no hablaba de la contraseña te hablaba del proceso

por cierto, para evitar el ataque de potencia puedes simplemente hacer algo terrible, que es hacer un proceso que sea tan ridiculamene extenso en proceso que sea muy lento como para dedicar un ataque de diccionario... es decir, puedes hacer un 100-DES XD

Claro que es posible. Si yo cifro el texto "a" y el resultado es "b", si no sabes la clave que utilicé, jamás sabrás que cifré el texto "a". Es imposible aún con infinita capacidad de cómputo. Todas las posibilidades son igual de probables. Da igual que tengas infinita capacidad de cómputo.

DiccionarioEjemplo = "abcdefg";
a = 1, b = 2, ..., g = 7;
while (x > dicTamaño) DiccionarioEjemplo -= 7;
a + g = 8; /* a */
b + f = 8; /* a */
c + e = 8; /* a */
d + d = 8; /* a */
e + c = 8; /* a */
f + b = 8; /* a */
g + a = 8;/* a */

no, existe probabilidad finita... ergo existe una potencial tal que...

y con la clave expandida por hash no? XD tu base es 8bit de largo en aes es 128 bits, aun así asumes que la tuya es imposible en base a computo...

por otro lado, recuerda que si el algoritmo es publico (y c omo programador sabes que a fin de cuentas siempre lo termina siendo asi sea a la fuerza) vienen los ataques estadisticos y allí es donde metodos con azar fallan porque a final de cuenta el azar es en la generacion pero si te dan cadenas continuas de unos o ceros van debilitando el algoritmo, por eso rijandel usa la tabla de intercambio estatica... porque la misma asegura que esto no pase...

No hace falta ni que el ordenador calcule. El algoritmo es tan simple que lo puedes calcular de cabeza. Tienes un diccionario de 100 caracteres? Pues 100 combinaciones posibles para 1 valor.
Cuando todos los algoritmos de uso frecuente se basan en capacidad de cómputo teórica... Puede que mañana se descubra una propiedad matemática que no se conocía, o una nueva forma de aplicar la tecnología y se puedan romper todos estos cifrados basados en que la capacidad de cómputo no es suficiente.

Tienes un diccionario de 100 caracteres? Pues 100 combinaciones posibles para 1 valor.

no son un diccionario de 100 caracteres... son 16 rondas con un diccionario de 2¹²⁸ caracteres (cada vez diferente) ya que el hash no queda puro, se hacen 2 procesos luego con el... a demas aunque consiguieras alguna forma de retornar un hash a su valor original, y luego pudieras reversar las piezas del hash, ellas mismas están mezcladas con la data...


XD realmente revisaste como se hace un sha256 y que hace rijandel? (ojo aes no es 100% rijandel, es basado en)


entiendes como funciona la matematica en ese aspecto? XD en tal caso sería un algoritmo

tu algoritmo (si es el mismo que ya llevabas) va en camino a ser el de la maquina enigma...

antes de negarte estudia los algorimos, ve los puntos fuertes y debiles, a demas que puedes tomar de ellos... no puedes mejorar algo si no conocces los mejores... por otro lado aes no es el mas fuerte al igual que sha, solo son solidos matematica y algoritmicamente (justamente a lo que expones, ya que fue probado contra eso) y aplicables en logica pura electronica... pero tienes otros mucho mas fuertes en todo aspecto que no cumplieron las caracteristicas de velocidad y aplicabilidad

Estoy muy perdido, pero creo que hubo un error en mi code y tal vez por eso no te funcione. Luego de intercambiar unas partes del array1, tienes que intercambiar los valores del array que hiciste de números. Eso no implica cambiar el array2, puedes crear otro para los números.

Yo te estaba hablando de mi algoritmo no de AES. Para usar Rijndael prefiero usar Serpent que es más seguro. Pero todos se basan en lo mismo.
Lo que te digo es que no tiene sentido que hashe la contraseña de mi cifrado porque el mismo depende de que el atacante no conozca la contraseña. Hashearla no sirve de nada.
Si conozco Rijndael, Serpent, DES, etc. Si conozco las propiedades matemáticas que dificultan el cálculo, si no, no haría un cifrado distinto.

En ciertos aspectos si tiene similitudes con Enigma. Por ejemplo se deben utilizar contraseñas distintas para cada cifrado. Uno de los mayores problemas que tuvo enigma fue que utilizaban una contraseña diaria, por lo que había días que los ingleses rompían el cifrado a primera hora de la mañana y podían obtener todas las comunicaciones en tiempo real de los alemanes para ese día. En mi caso el planteamiento se asemeja mucho a un One-Time-Pad (libreta de un solo uso). Con ajustes para eliminar la correlación del texto plano con el cipher text, la libreta de un solo uso es 100% irrompible. El mayor problema para su uso reside en el intercambio de claves y en que el cifrado guarda correlación. Utilizando un IV por cada cifrado generado y con algunos ajustes no sería extrictamente necesario cambiar la clave para cada cifrado. En la elección de Rijndael como estandar  aes había chanchullo ya que se uso hardware favorable y se priorizó velocidad sobre seguridad. Serpent era más seguro y en el propio hardware de la época la diferencia de velocidad era imperceptible. En cambio optaron por utilizar procesadores de pocos HZ para aumentar la diferencia de velocidad y así disponer de un cifrado que los gobiernos pudiesen romper.

claro porque los criptografia es una religion, todos la aceptan, no la juzgan y nadie tiene el conocimiento para ponerlo a prueba XD


e insisto.... no hablaba de la contraseña... hablaba del procedimiento de rondas... y la contraseña se hashea para exetenderla a un modo standard...

Leyendo parece que se esta hablando de un Verman (o algo asi porque deriva en este tema la barca hacia lados curiosos :) ). No se si se ha dicho ya, pero lo de usar claves igual de largas que el mensaje esta muy bien a nivel teórico pero no funciona a nivel práctico.
Verman ya mola y cualquier equivalencia usando ordenación o cualquier otra cosa similar esta bien pero ninguna de las opciones (verman original o derivados) mola tanto a nivel práctico. Como le tienes que pasar al receptor la secuencia de caracteres por una via segura, y es del mismo tamaño, Joder simplemente pásale el mensaje por esa vía segura. :)
Para que el cifrado sea util, el intringulis del asunto siempre está en lo mismo, conseguir pasar la pass simétrica, que debería ser pequeña, por un medio seguro dentro de un canal inseguro y que el mensaje que sale tenga suficiente entropia. Y ahi el poder de cómputo tiene al voz cantante.

Tal cual está ahora mismo es exactamente un Vernan. En Github tengo una implementación en PHP en la que explico exactamente esto. Que diseñando mi cifrado llegué a la misma conclusión y un diseño similar al de Vernan. En el PHP utilizo bloques de 7 bytes con diccionario de 127 caracteres. Coincido con todo lo que dices.

El tema está en el uso que se de al cifrado. Por ejemplo puedo mejorar la seguridad de una base de datos aplicándole el cifrado y por tanto la contraseña no necesita ser intercambiada. El problema que quiero solventar es el de la correlación para hacer el cifrado irrompible. Esto me permitiría operar con bases de datos alojados en servidores externos.

Uso práctico:
-Creo base de datos con datos de mi empresa.
-La cifro para poder hostearla en servicios externos y que no me suponga coste extra.
-Para operar descargo el archivo que desee. Lo descifro de forma local. Utilizo la información.
-Cifro con nueva contraseña al estilo One-Time-Pad y vuelvo a almacenar el contenido que utilicé en la base de datos.

Pero el tema es que la longitud de la clave es la misma que los datos almacenados. Lo que almacenas en otros sitios no vale para nada, ose me refiero la longitud de los datos que almacenas de forma remota y de forma local son de la misma longitud. Entonces no veo muy bien la utilidad de tener esos datos que solo tienen sentido con tu password local almacenados de forma remota.
Osea, si la idéa es que no puedan coger los datos si no estás tu delante, bajo mi punto de vista, me parece casi mejor idea llevarte un USB/CD del mismo tamaño de los datos almacenados lleno de números aleatorios y descifras con eso cada vez que desees utilizar la base de datos. El USB por lo menos verás cuando te lo roban. :) Y no pueden cogerte las credenciales 365/24. La posibilidad de copia, la tendras igual, pero al menos no dependerás de como lo guarda un tercero y dependerá sólo de ti.
No obstante a nivel práctico, yo personalmente tiraria de cualquier cifrado simétrico con clave suficientemente larga.
Pero es sólo mi punto de vista. :) puedes no estar de acuerdo.

Cual es el problema de que tengan el mismo tamaño? Qué indicas al atacante cual es el tamaño de la cadena original y el tamaño de la clave que tiene que probar? O cual? Yo creo que da igual una vez se rompa la correlación entre plaintext y ciphertext ya que pruebes lo que pruebes nunca sabes cual es el resultado correcto debido a que todas las combinaciones posibles. Es decir, un texto cifrado de 4 caracteres a descifrar te dará todas las palabras posibles de 4 caracteres, ya sea en español, inglés, etc.

PD: Pensando sobre la correlación podría usar 3 capas de cifrado al estilo tripleDes, pero sin necesidad de cambiar la clave por cada capa, ya que lo que importa es que no exista correlación para análisis estadístico. Se pueden hacer mucha cosas.

si haces 3des con una misma contraseña la fuerza es la de 1 des, ya que solo tienes que repetir 3 veces en 1 solo bloque que hoy dia con la fuerza de des es perfectamente viable