Como siempre muy interesante APOKLIPTICO. Mucho por leer y por madurar pero ahora mismo me asalta una duda

Actualmente pensamos en un plain text como una colección de caracteres ascii pero ¿qué pasa si el texto a cifrar por muy plain que sea está en unicode?

Porque ahí cada caracter es representado por un mínimo de dos códigos y en el caso de ideogramas chinos hasta cuatro según tengo entendido. Desde un punto de vista criptográfico da igual cifrar algo que tenga 8 bytes que algo que tenga 16 pero desde el punto de vista de la desencriptación no.

¿o es que tengo mal entendido el unicode?

Lo demás ya lo iré leyendo con calma que este es un tema que hay que tomar a pequeños sorbos.

 

Bien, pues tu usa eso si te hace feliz.

Yo usaré gmp que trabaja con esos valores directamente en binario y me hace feliz a mi.

Aparte de que si miras ese código verás o que está incompleto o no funciona. A mi me da igual porque no pienso usarlo je je je pero bueno. Aun suponiendo que funcionara ¿echamos una carrera a ver quien resuelve antes 894689038903^766656565656565 mod 8949083489008989090309

Porque en gmp eso es

 

P.D.
Que no te suene que me rio de ti o algo. Nada mas lejos. Solo tengo interes en la gente que está aprendiendo C que vea las posibilidades de esto para superar los límites naturales de C. Nada mas que eso. Por eso me he extendido en la respuesta.

Un saludo

Efectivamente no es estandar pero a veces es necesario y en absoluto veo que las operaciones que podrías necesitar con números grandes puedan resolverse con strings.

Bueno, poder poder lo que es poder seguramente se podrá (de hecho esas funciones de alguna forma se computan) pero intenta calcular un número de cincuenta dígitos elevado a uno de 100 a base de strings por ejemplo.

No son casos habituales pero tampoco son extremadamente raros. Por ejemplo seguramente si excedes 20! ya estas sobrepasando los tipos comunes. Que la gente habitualmente no anda calculando 50^50 o 50! estoy de acuerdo, pero creo que en diversas actividades es bastante probable encontrarse con ese tipo de problemas.

Un saludo
 

Eso si es lo que busco o al menos lo parece (a falta de pruebas)
 

He mirado eso de gmp.h y creo que la cosa pasa por instalar los paquetes libgmp-ocaml y libgmp3c2 (en debian).

Esto si parece ser lo que buscaba.

Si que me gustó la criptografía. Es una ciencia aparte y un nuevo reto je je je. Igual me ha pasado con Gambas como lenguaje de programación para sustituir a VB y en entornos linux. Disfruto con ello.

Muchas gracias
 

Lh: No hagas doble post, utiliza el botón modificar.

Ya lo he solucionado. Ahora que lo veo no es tna dificil pero ha habido un rato que no enteraba por donde me venían las cosas.

Primero para instalarlo hay que instalar los paquetes libgmp3c2 y libgmp3-devel.

Una vez instalado hay que conocer las funciones que incluye para trabajo con bignum. La documentación de esas funciones está aquí

http://gmplib.org/manual/index.html#Top

Y mas concretamente las funciones correspondientes están aquí
http://gmplib.org/manual/Function-Classes.html#Function-Classes

Y ahora pongo un ejemplo de crear un número grande y hacer una suma con él. Luego se muestra en pantalla.


Primero inicializo x, y y z. Luego asigno a x un valor que especifico que está en base 10. Asigno a y el valor 1 y especifico que está en base 10. Luego sumo x e y y dejo el resultado en z que hasta ese momento valía cero. Por último saco por stdout el valor de z.

Muchas gracias
 

[editado]
Olvidé decir que para compilarlo hay que incluir obligatoriamente la librería gmp o no funcionará.
Es decir pra compilar la anterior aplicación y que funcione habrá que hacerlo así
gcc prueba.c -lgmp -o prueba

[/editado]

Efectivamente tal como dices no es posible utilizar coma flotante y de hecho aún así habría un límite (mayor pero límite) que lo hace inviable. Podría ocurrir que pudieras calcular 50! y no pudieras 51! por ejemplo. La naturaleza de big int es "cualquier tamaño" y lo que si puede pasar es que según la cpu que tengas la operación pueda llevar mas o menos tiempo.

En google veo que algunos códigos hacen un include "bigint.h" y a partir de ahí ya se puede trabajar con ese tipo de números, pero no consigo información de donde obtenerlo.

Un saludo

Hombre claro que los long son mayores que los int pero eso no son big int. Un big int puede tener 200 dígitos.

Estoy trabajando en unos test de primalidad (miller-rabin) y no tengo problema con números muy pequeños pero con números de dos o tres cifras ya no puedo. Lo correcto sería trabajar con números de mínimo veinte cifras osea que el long no vale ni de coña. Intenta calcular 50^100 o 60! o cualquier cosa asi con el tipo long.

Yo creo que hay alguna librería que se incluye y que tiene funciones para eso pero no se donde encontrarla ni nada. Por eso pregunto.

Un saludo

Pues eso.

¿Como defino en C un tipo bigint o similar que admita números grandes? ¿hay alguna librería? ¿como se hace?

Ya pero es que al final ¿no estas haciendo una forma primaria de certificado?

Porque al utilizar criptografía asimétrica estas creando una relación de confianza entre ambas partes que te lleva a dar una clave que otorga al receptor en un espacio de confianza adicional. Los certificados son mas elaborados, pero en lo básico estamos en eso.

De todas formas creo que te estoy desviando el interesante hilo así que me callo y leo que tengo mucho que aprender je je je

 

Mucho gusto conocerte.

Efectivamente.

El problema es que si quieres usar criptografía simétrica tendrás que enviar al receptor la clave para que pueda leer lo que le enviarás. Si el envío de esa clave lo haces por medio de criptografía asimétrica aseguras que quien recibe esa clave es quien debe ser y nadie mas. Si no lo haces así no puedes tener la seguridad de que esa clave no haya caído en malas manos. Si de lo que se trata es de seguridad es un factor a tener en cuenta. De hecho tengo que verlo mas profundamente pero ¿no es eso en definitiva lo que hace ssh?

Por cierto para temas de test de primalidad y semillas tengo una lista de los 10.000 primeros números primos si a alguien le interesa que me lo haga saber.

Un saludo

Un hilo muy interesante apokalipto.

Pongamos el caso de que yo deseo establecer una relación segura (tipo ssh) con otra máquina osea que A desea establecer una relación segura con B.

La primera vez que establezco la conexión tengo que encontrar la forma de enviarle una clave de un sistema simétrico. Esa clave no se puede enviar en una transmisión abierta porque podría ser conocida por una tercera parte (man in the middle)  y por tanto podría conocer cualquier cosa al conocer la clave de cifrado.

Así que los pasos a seguir son:

1. Conexión a la máquina B.
2. Envío de mi clave pública.
3. Recepción de su clave pública.
4.  cifro un mensaje en el que está la clave dei algoritmo simético que usaré. La cifro con su clave pública.
5. Cuando B recibe mi mensaje puede descomprimirlo porque ha sido codificado con su clave pública y el tiene su clave privada. Al leer ese mensaje conoce la clave que usará para leer mensajes

Las demás veces ya no necesitaré todo eso pues tanto A como B conocen la clave de abrir mensajes

En todo esto, un posible man in the middle no ha podido obtener ninguna información válida porque no tiene la clave privada de A ni la de B.

Ahora bien estas son mis dudas:

Todo esto para poder enviarle una clave de un protocolo simétrico que es mas seguro y eficiente; sin embargo ya pude enviar un mensaje seguro utilizando un sistema asimétrico así que ¿para qué quiero el simétrico? Osea ¿en que casos merece la pena dar estos pasos para enviar a otra parte una clave de un protocolo simétrico?

Supongo que si yo tuviera que tener una clave distinta para cada posible interlocutor necesitaría muchas claves y eso lo resuelvo mejor con la clave/privada/pública. Sin embargo con el sistema simétrico puedo tener una sola clave para datos particularmente importantes y común a todos los interlocutores. El riesgo de esto es que el conocimiento de esa clave abre el sistema por completo y por tanto hay que tener especial cuidado en donde se almacenan (igual que donde se guarda la clave privada).

Al final de todo esto lo que estoy haciendo es un certificado propio ¿no es así?

 

Por otra parte en mi modesta opinión quien quiera introducirse en criptografía debe hacerse cargo que el código va en C o en ensamblador y que todo es pura matemática. Por esa razón aquellos que realmente se interesen en estos temas deberían darse un paseo por el foro de C. Por poder se puede implementar en vb o php si se quiere, pero este es el reino de C y de ensamblador.

Para quien no lo sepa eso que dije de "man in the middle" es una técnica hack que se usa para conocer los mensajes que una parte dirije a otra. En la práctica es oir lo que A dice a B y por tanto parece lo mas adecuado para intentar averiguar claves de códigos cifrados.