[LACNIC/Seguridad] Consulta cripto asimétrica

Carlos Pantelides carlos_pantelides en yahoo.com
Lun Mayo 27 19:51:29 -03 2019


Alejandro:
Si el curso es el de Boneh, es una terrible frustración, ya dos veces llegué hasta cerca de 3/4 y mis falencias matemáticas me dejaron afuera, pero es tan claro ese señor!!

Lo del proxy reverso: los proxies reversos y otros artefactos deben abrir el TLS y probablemente establezcan otro TLS con el destino final. Entonces, un atacante interno parado en el proxy puede ver los datos en clear text.
El deseo de que dos cleartext iguales generen distintos cyphertexts, que responde a razones obvias (que no pueda usar el sistema como oráculo) entiendo que se puede concretar agregando algun rnd() por ahí, la librería que estoy usando afortunadamente ya lo hace solita.
Voy a mirar mis copias locales del curso y gracias

--
Carlos Pantelides
@dev4sec
https://github.com/cpantel
https://seguridad-agile.blogspot.com/ 

    On Monday, May 27, 2019, 8:27:08 AM GMT-3, Alejandro Acosta <alejandroacostaalamo en gmail.com> wrote:  
 
  
Hola Carlos,
 
  No creo poder ayudarte tanto pero al menos intentaré darte un pequeño apoyo.
 
  Exactamente la respuesta a tu pregunta se encuentra respondida en el curso de Criptografía en Coursera de la Universidad de Maryland.
 
  Ahora bien, por otro lado, no creo que tu pregunta tenga una sola respuesta, la inmensa mayoría de los algoritmos sufren del concepto de: cyphertexts expansion (por ejemplo el de Julio Cesar no). La expansión va a venir dada por varias variables, entre ellas el tamaño de la llave, del IV, y el modo de operación del cifrado (CTR, CBC), lo bonito de todo esto es que el texto introducido (m) puede ser de tamaño arbitrario (claro, exceptuando One Time Pad y algún otro) para lograr generar c
 
  Respecto al proxy reverso, no estoy seguro cual es tu preocupación, todos ellos pueden operar en SSL/TLS sin problemas.
 
  Finalmente, que dos cleartext (m) generen dos cyphertexts diferentes puede depender de muchas razones, la llave diferente y/o el Initialization Vector
 
 
 
  Espero alguien más te pueda ayudar un poco más.
 

 
 
Saludos,
 

 
 
Alejandro,
 

 
 On 5/26/19 7:38 AM, Carlos Pantelides wrote:
  
 
 Hola 
  Entiendo que para proteger mensajes, el rol de un algoritmo asimétrico suele ser cifrar/descifrar la clave de un algoritmo simétrico con el cual efectivamente serán cifrados/descifrados los mensajes y esto es así por la abismal diferencia de performance entre ambos tipos de algoritmos. 
  Pero, si yo quisiera transmitir mensajes con una longitud muy reducida, tal que los mensajes son apenas más largos que esa clave asimétrica, no tendría sentido desde ese punto de vista introducir 
  
  Si lo anterior no es correcto, ¿qué no estoy entendiendo?
  
  Si lo anterior es correcto: 
  Estoy implementando protección de mensajes de extremo a extremo, suponiendo que pese a tener TLS no puedo confiar en algún elemento intermedio, por ejemplo la existencia de un proxy reverso.
  
  Estoy utilizando RSA, en particular la implementación en javascript de Travis Tidwell (https://github.com/travist/jsencrypt) que dice estar basada en el trabajo de Tom Wu (http://www-cs-students.stanford.edu/~tjw/jsbn/)
  
  Ya he considerado que dados dos cleartexts iguales, los cyphertexts no sean iguales, de hecho eso lo provée el algoritmo. 
  ¿Estoy en el camino correcto? ¿Sugerencias o correcciones?
  
  
  Gracias y saludos
   
  _______________________________________________
Seguridad mailing list
Seguridad en lacnic.net
https://mail.lacnic.net/mailman/listinfo/seguridad
 _______________________________________________
Seguridad mailing list
Seguridad en lacnic.net
https://mail.lacnic.net/mailman/listinfo/seguridad  
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20190527/467e001c/attachment.html>


Más información sobre la lista de distribución Seguridad