Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - kub0x

#541
Buenas LaiaxanIV,

he hecho un code en C# como prueba para cifrar/descifrar un número cualquiera. He de decir que la construcción de la clave privada 'd' la he hecho a mano utilizando el concepto de la multplicativa inversa, sin emplear el extended euclidean (el cual yo recomiendo).

Para calcular la clave privada simplemente calculamos la inversa de 'e' en 'phi' ((p-1).(q-1)). Y me dirás, joe pero en tu método tienes que saber el totient de phi, phi((p-1).(q-1)), por lo tanto tienes que conocer la factorización de (p-1).(q-1). Claro, pero en este ejemplo es trivial calcularlo, porque son números pequeños, sino sería una locura, ya que tendríamos que conocer la factorización de 'n' y de phi(n).

Obtenemos 'd' de la siguiente forma:

d = e ^ phi(phi(n))- 1 (mod phi(n))
d = e ^ phi(phi((p).phi(q)))- 1 (mod (phi(p).phi(q))
d = e ^ phi((p-1).(q-1))- 1 (mod ((p-1).(q-1))

Código (csharp) [Seleccionar]

BigInteger p = 14188273085411836729, q = BigInteger.Parse("280615323801319888452039197798402115977");
BigInteger n = BigInteger.Multiply(p,q);
BigInteger phi = BigInteger.Multiply(p-1, q-1);
BigInteger phiphi = BigInteger.Parse("646779039649951876929832079791621951934669155860480000000"); //Calculado en http://www.numberempire.com/numberfactorizer.php simplemente multiplica el totient de p-1 por el totient de q-1 y tienes el totient del totient
BigInteger d = BigInteger.ModPow(65537, phiphi-1, phi);
BigInteger r = BigInteger.ModPow(BigInteger.Multiply(65537, d), 1, phi);
Console.WriteLine(r); //Comprobamos que la multiplicativa inversa se cumple e.d (mod phi(n)) = 1
BigInteger c = BigInteger.ModPow(12345, 65537, n); //Calculamos el ciphertext 'c'
BigInteger m = BigInteger.ModPow(c, d, n); //Recuperamos el mensaje original
Console.WriteLine(m);


Saludos!
#542
Todo se resume al teorema del resto anteriormente citado (Arimética modular). Los múltiplos no tienen porque ser iguales o mayores, -4 = -2*2, por lo tanto el -2 múltiplo de 2. La aritmética modular tampoco se rompe con negativos, sino revisar grupos abelianos https://en.wikipedia.org/wiki/Abelian_group

Sobre la paridad del 0:

https://en.wikipedia.org/wiki/Parity_of_zero
http://math.stackexchange.com/questions/1113709/is-zero-an-even-number (ojo que esta es una comunidad matemática de ÉLITE)
#543
¡Pero bueno! Yo os mandaba de nuevo a preescolar.

Un ejemplito:

6 es el 3 múltiplo de 2 porque: 6 = 3x2
0 es el 0 múltiplo de 2 porque: 0 = 0x2

Espero que haya quedado claro. M es múltiplo de n si n divide a M. Esto se reduce a 0 = M (mod n) por lo tanto 6 (mod 2) = 0 (2 divide a 6) y 0 (mod 2) = 0 (2 divide a 0).

Saludos!
#544
Buenas,

llego tarde pero aporto mi granito de arena. Ya hace tiempo (in the 90's) entre los criptólogos había debate entre usar la palabra "crypt" y "cipher", personalmente utilizo "encipher"/"decipher" cuando escribo en dicho idioma, recuerdo que esta polémica la vi en el blog de Bruce Schneier (El chuck norris de la crypto). http://english.stackexchange.com/questions/66164/what-is-the-semantic-difference-between-encipher-and-encrypt

Como veís es por conflicto entre otras lenguas. Paso de entrar en el debate de las palabras acogidas por la RAE (RAE=diccionario de chonis de barrio) y de la evolución del castellano :P

Saludos!
#545
Lo óptimo sería guardar la clave privada RSA cifrada con AES-GCM ya que GCM provee de aunteticación e integridad. De esta forma también puedes detectar modificaciones sobre el ciphertext.

Otras alternativas serían crear dos claves simétricas, una para AES-CBC y otra para CMAC, ambas derivadas de una MasterKey mediante una PRF (SHA-256 preferiblemente). Pero con GCM te ahorras el usar dos keys, es como aplicar un MAC al cifrado, todo en uno.

Saludos!
#546
Buenas arget,

Realmente lo que haces es utilizar RSA como modo de bloque de cifrado y para eso hay alternativas mejores. Revisa el PCKS1# (https://tools.ietf.org/html/rfc3447) y verás que en su modo recomendado de firma pasa directamente todo el octeto, lo recomendable es pasar el hash del octeto.

Info adicional:

hace un tiempo se me ocurrio que colisionando el hash en N bits de un cert x509v3 lícito y uno falso podría dar a pie a una forgery de la firma digital al ser firmada por la CA. Así que pregunté a ver si realmente RSA utiliza la data como chunks, si se utiliza un digest para firmar es para acortar el chunk y hacerlo inferior al tamaño del módulo (en tu ejemplo no hasheas, pero es un ejemplo :D ). Revisa mi post: https://crypto.stackexchange.com/questions/26562/rsa-signature-forgery
#547
Simplemente se han sumado a la iniciativa china (Great Firewall project) https://en.wikipedia.org/wiki/Websites_blocked_in_mainland_China
#548
Corregido, eran 94, tienes razón. Era tarde y me equivoqué jajaja pero bueno el tema queda ahí. Haz pruebas sobre los casos que he presentado e intenta añadir alguna protección extra para que podamos ayudarte a securizarlo un poco más.

Te recomiendo leer sobre cifrados por bloque y álgebra modular, pues son principios en los que se basan algunos de los cifrados estándar modernos.

Saludos!
#549
Buenas Alberto,

he posteado en cryptostackexchange una pregunta relacionada con tu cuestión -> https://crypto.stackexchange.com/questions/34155/storing-rsa-private-key

Si sólo necesitaras implementar un protocolo de comunicación segura basada en criptografía híbrida (AES + RSA/DH/ECC) te recomendaría DHE o ECDHE pero veo que tienes que firmar no te queda otra que guardar la privada.

Saludos!
#550
Muy buenas JoseluCross,

he probado tus dos vertientes del algoritmo de cifrado, la primera dónde simplemente reiniciabas el contador de la clave para cifrar de N en N bloques (donde N es el tamaño de clave) y la segunda la cual incrementas el valor de cada carácter de la clave por cada bloque de tamaño N.

Supongo que en la segunda vertiente intentabas arreglar el tema de los espacios.

Problemas en primera versión: Los espacios al ser sumados en la clave pueden exceder el tamaño 126, por lo que reducirías en 94 su peso. Cuando eso no sucede, simplemente basta con restar a todo el ciphertext el número 32 para obtener los caracteres de la clave.

Problemas en segunda versión: Aquí cuando el bloque a cifrar se acaba, a parte de reiniciar el contador "passPosition", incrementas en uno el peso de cada carácter de la clave. Por lo que si el cracker conoce el tamaño de clave, puede dividir el texto en bloques relacionados con la clave, y contar los incrementos, todo ello en zero index. Un ejemplo sería:

HOLA (pass) este es un mensaje super secreto y nadie nunca lo va a descifrar (plaintext). 64 length el plaintext, 4 length la pass -> 16 bloques, en zero index 15, por lo tanto 15 incrementos por caracter en la clave.

Notése que en ambos casos, aún restando 94, sería fácil obtener el password.

Te dejo dos capturas, la primera corresponde a la V 1.0 y la segunda a la V 2.0 (el code del github):





Fíjate como en la segunda hasta se aprecia "HOLA" de seguida. Fíjate que los caracteres alfábeticos en su mayoría son H, O, L y A (no sería muy díficil deducir incluso a ojo la clave) alguno que otro alfabético hay, y el resto son númericos/símbolos.
Simplemente habría que restar a cada carácter del ciphertext (texto cifrado) 32 y 15 para obtener la clave en cuestión.

No he querido meterme en análisis estadístico, pero bueno no creo que me tomara mucho montarme un escenario en el lenguaje R.

Saludos!