[LACNIC/Seguridad] Consulta cripto asimétrica

[Alejandro Acosta]

On 5/27/19 6:51 PM, Carlos Pantelides wrote:
> 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!!


El curso es de Jonathan Katz (https://www.coursera.org/instructor/~79127)

Link del curso: https://www.coursera.org/learn/cryptography


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


Muy cierto


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


Suerte y si solucionas avisa como :-) 



>
> 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
> <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 <mailto:Seguridad en lacnic.net>
> https://mail.lacnic.net/mailman/listinfo/seguridad
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net <mailto: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/20190529/58afb138/attachment.html>
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 1782 bytes
Desc: no disponible
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20190529/58afb138/attachment.key>