Mensajes

Kub0x, yo no sé si no he entendido su pregunta, pero creo que el busca almacenar de manera segura su clave privada. Es evidente que es necesario cifrarlo mediante un algoritmo simétrico, sin embargo, como comento arriba, si el texto cifrado y la clave se encuentran en el mismo sistema la seguridad es casi nula. Supongo que sería más pertinente hablar de la manera de almacenar de manera segura la contraseña simétrica en lugar de hablar de en qué algoritmo hay que emplearla.

Si me he perdido algo explicádmelo, por favor.

Tienes el comando choice. Con eso te debe bastar.

Ah, vale, pero eso me parecía demasiado ineficiente, se necesitan hacer potencias enormes para mensajes de apenas 4 letras, incluso usando la potenciación binaria [ https://es.wikipedia.org/wiki/Exponenciaci%C3%B3n_binaria ]. Pero sí, debe ser así, haré pruebas midiendo tiempos y demás.
Gracias!

Sinceramente no sé de java demasiado, pero creo que podemos entendernos.
Yo creo que bastaría con declarar un array 'a' de booles de 10000 elementos, todos a 0. Cuando grita "entra 1101" tu pones a[1101] = 1. Cuando grita "sale 1101" poner a[1101] a 0.
Cuando grita "tenemos" haces un bucle recorriendo todo el array, cuando te sitúas en un elemento compruebas si está a 0 o 1, si está a uno lo muestras por pantalla, en C sería algo así:

Código [Seleccionar] Expandir


printf("tenemos\n");
int i;
for(i = 0; i < 10000; i++)
{
   if(a[i] == 1) printf("%i\n", i);
}


Huolas criptógrafos. Tengo una duda bastante baladí sobre el RSA, pero no logro imaginarme cómo lo solucionan. Esto también puede servir a quién no logre entender el RSA, pues pondré un ejemplo sencillito para mostrar mi dudita.
El RSA en realidad solo define 3 algoritmos, el de generación de claves, de cifrado y de descifrado (estos dos últimos sirven para comprobación de firma y de firma respectivamente, ya lo veremos).
El primero consiste en:
1. Elegir primos p y q. Yo elijo p = 13 y q = 97
2. Calcular n = p * q = 13 * 97 = 1261
3. Calcular φ(n) [se lee "fi de n", donde φ es la función de Euler] = (p - 1) * (q - 1) = 12 * 96 = 1152
4. Elegir e tal que gcd(φ(n), e) = 1; e < φ(n). Esto es que el mcd de e y φ(n) sea 1 (en otras palabras que sean coprimos o primos relativos entre sí) y que e sea menor que φ(n). En este caso elijo e = 23 [no olvidemos que un primo es comprimo con todos los números].
5. Elegir d tal que haga verdadera la siguiente expresión: d * e mod φ(n) = 1 y d < φ(n). En este caso
d * 23 mod 1152 = 1; solo hay una opción que yo he obtenido mediante un pequeño programa que dejo al final, solo hay una opción: 551.

La clave pública es: KU = {e, n} = {23, 1261}
La clave privada es: KR = {d, n} = {551, 1261}

Ya tenemos nuestras claves. Ahora vamos al algoritmo de cifrado:
C = M^e mod n
Esto es que para cifrar hay que elevar el mensaje M a e y calcular el resto de su división entre n.
Defino una tupla M.
M = {'H', 'O', 'L', 'A'}
Según el ASCII tenemos M = {72, 79, 76, 65}
Siguiendo que M_0 = 72 y M_1 = 79 entenderéis esto:
C_0   = M_0^e mod n = 72^23 mod 1261 = 5,231755239×10^42 mod 1261 = 1133
C_1   = M_1^e mod n = 79^23 mod 1261 = 4,420008451×10^43 mod 1261 = 27
C_2   = M_2^e mod n = 76^23 mod 1261 = 1,814314713×10^43 mod 1261 = 253
C_3   = M_3^e mod n = 65^23 mod 1261 = 4,9774534×10^41   mod 1261 = 676
C     = {1133, 27, 253, 676}

Para descifrar es:
M' = C^d mod n
Si habéis entendido hasta aquí, esto también. Y lo siguiente igual:
M_0'  = C_0^d mod n = 1133^551 mod 1261 = 72
M_1'  = C_1^d mod n = 27^551   mod 1261 = 79
M_2'  = C_2^d mod n = 253^551  mod 1261 = 76
M_3'  = C_3^d mod n = 676^551  mod 1261 = 65
M'    = {72, 79, 76, 65} = {'H', 'O', 'L', 'A'}

Para firmar lo que se debe hacer es "cifrar" pero con tu clave privada, el receptor para comprobar que el mensaje ha sido cifrado por ti necesita "descifrar con tu clave pública".
PGP/GPG implementa cifrar y firmar a la vez, para esto primero calcula el hash del mensaje, lo firma (con la clave privada del emisor), lo añade al principio del mensaje (aquí suele comprimir mediante ZIP), despues cifra simétricamente tanto el hash como el mensaje mediante una clave de sesión aleatoria, cifra dicha clave mediante RSA con la clave pública del receptor, añade la clave cifrada al principio del mensaje y envía el paquete. El receptor recibe el paquete, descifra usando su clave privada la clave de sesión simétrica cifrada que se encuentra al inicio del paquete, con esta descifra el resto del paquete, descomprime extrae el hash firmado, comprueba que sea del emisor legítimo, calcula el hash del mensaje y compara el que acaba de calcular con el firmado. Punto. Simple, ¿eh?
Ni que decir tiene que no siempre se firma o se cifra, puede solo cifrarse o solo firmarse. Pero ni lo uno ni lo otro tienen que ver ahora con esto. Me he ido por las ramas.

De acuerdo, ahora viene mi pregunta.
El texto cifrado {1133, 27, 253, 676} se tiene que enviar como bits [gracias, Sara].
Bien, esto se representa en hexadecimal del siguiente modo {0x046D, 0x1B, 0xFD, 0x02A4}
Así que tenemos cuatro bytes: 04 6D 1B FD 02 A4, sin embargo, si yo envío esto, ¿cómo sabe el receptor qué bytes corresponden a un único byte? Porque está claro que la letra 72 que ocupa solo un byte, al cifrarse ocupa dos bytes, y para desifrarse habrá que tratarlo así.
Sé que esto no lo define el RSA, que este solo define esos tres (o cinco) algoritmos, por eso en realidad la pregunta es: ¿cómo lo implementa PGP/GPG?
Me puedo imaginar que separa los caracteres cifrados mediante bytes nulos, o, ahora que lo pienso, lo mismo no cifra carácter a carácter. Bueno, no sé, tengo la curiosidad, si alguien sabe decírmelo...
Gracias de antebrazo.

Ejecuta el comando "help" en la consola, hay cierto () comando que te servirá para trabajar con lo de detectar qué tecla se pulsa y demás.
Para saber si existe un archivo tienes el "if exists". En este foro tienes tutoriales muy buenos sobre batch avanzado. Sin dudarlo léelos, es bastante buena base para empezar en la programación, después sigue con C (es mi recomendación).

Si necesitas más ayuda pídela.

P.D.: Así, sin venir a cuento, te digo "choice", interprétalo como quieras

No he mirado tu código (pereza jeje), pero si lo que haces es simplemente implementar ASCII 32-126 será igual pero empleando un alfabeto más grande, cuál es el carácter del ASCII que más se repite en inglés y en castellano?, la 'e' y después la 'E'.
De todas formas el método que te ha dicho Laiaxan no es válido contra el cifrado de Vigenère. Vigenère es polialfabético, por tanto un carácter no será siempre el mismo en el criptograma, del mismo modo, un carácter en el criptograma no representará siempre al mismo carácter. Sin embargo tiene su técnica similar. En textos largos con claves de cierto tamaño aparecen en el criptograma cadenas que se repiten cada cierto tiempo, esas cadenas, si suponemos que no son coincidencia, son zonas en las que un texto cifrado coincide de nuevo con la clave, veamos (clave "ABCDEFG"):

Código [Seleccionar] Expandir


asdasdasdasdEJEMPLOasdasdasdEJEMPLOasdasdasda...
ABCDEFGHABCDEFGHABCDEFGHABCDEFGHABCDEFGHABCD...

En el criptograma se verá que en donde EJEMPLO coincide con EFGHABC se repetirán los caracteres cifrados. Con esto podemos saber que la distancia entre repetición y repetición es un múltiplo de la longitud de la clave. Esto se evita mediante el one-time-pad, que es la generación de una clave aleatoria de la longitud del texto a cifrar.

~ (así te llamas), eso no sirve, porque según entiendo pretende que su programa no dependa del usuario, es decir, que el usuario no tenga que lidiar con este en ningún momento. Esto exige claramente que el programa tenga los medios para obtener la clave. Esto es un grave problema, es equivalente a cerrar la puerta y dejar la llave al lado y (prácticamente) a la vista, cualquiera que acceda al ordenador tendrá acceso al archivo cifrado y su clave, aunque la clave se encuentre escondida o dentro del programa o donde sea, o incluso si la clave se genera en tiempo de ejecución, se puede reversear el programa para ver cómo se genera y obtenerla. Sin embargo, solo se me ocurren dos opciones:
La primera es mandar la clave a un servidor remoto con contraseña, esta contraseña podría ser la misma que la contraseña de login del usuario o una derivada de esta, la contraseña del usuario podrás arreglártelas lidiando con el sistema operativo para tener acceso a ella (se me puede ocurrir quizá en lugar de usar la contraseña en sí, usar una derivación del hash almacenado en /etc/shadow o en C:/WINDOWS/System32/config/*, no emplees el hash en sí, porque aunque sea el hash se puede intentar atacar si alguien lo captura on air, por supuesto la conexión con el servidor remoto debe ser segura, como SSH).
La segunda sería generar la contraseña en tiempo de ejecución de manera aleatoria, esto es, al ejecutar el programa por primera vez este aleatoriamente creará un algoritmo de generación de contraseña, este será codificado biinariamente de una manera que solo tu programa conocerá, en un archivo con los mismos permisos que el shadow, cuando se vuelva a ejecutar el programa, este leerá e interpretará el algoritmo escrito en dicho archivo, cogerá la variable del sistema necesaria para ejecutarlo (como bien dices puede ser el UUID de una partición en la máquina), completará el algoritmo a partir de esta variable y obtendrá la contraseña (evidentemente todos los datos confidenciales se deberán borrar inmediatamente mediante una función memset modificada para ello).
Todo esto solo molestará un poquito a cualquier atacante, sin embargo puedes y debes ofuscar el código (existen programas para eso). Eso fastidiará bastante más, de todas formas, solo retrasa lo inevitable. Todo esto dejando de lado que tu programa será de código cerrado, si es de código abierto todo será en vano.
Yo lo que te he propuesto es una forma de ofuscar el código, por supuesto lo puedes hacer todo mucho, muchísimo más lioso, pero esto es anticriptográfico, anti-principios de Kerkchoffs, la seguridad de un sistema no debe depender de que su diseño permanezca en secreto.

En realidad la solución más simple y correcta sería pedir una contraseña al usuario o emplear la contraseña de login del usuario obtenida tal cual (en texto plano) de la forma que veas (en relación con el SO), o su hash del shadow.

Puedes usar el argumento %0 con el comando delete.

No sé, yo sigo sin ver ninguna relación con el AES, supongo que no te he entendido bien. Respecto a Winbugs, que yo sepa sí implementa todos los FIPS, de hecho existen opciones para configurar ciertas características (como el cifrado en WiFi) para que funcionen solo bajo FIPS.

Pfff, no sé yo creo recordar en textos de 2007 que los FLOPS en un ordenador personal raramente alcanzaban el GigaFLOP, sin embargo mucho progreso ha habido desde entonces y me suena que ahora lo normal está en los 3 GFLOP.Todo esto sin poder darte fuentes.
Basta una búsqueda rápida para encontrar que los FLOPS se calculan mediante esta sencilla operación:
Número de núcleos * Frecuencia por núcleo * Número de FLOPs por ciclo
Puede parecer que lo último no tenga sentido, pero fíjate, no es FLOPS, es FLOPs, no es por segundo, es por ciclo, el problema es que este último dato no resulta fácil de conseguir.
No he tenido tiempo de investigar mucho, aquí tienes las fuentes:
http://scicomp.stackexchange.com/questions/11306/how-to-determine-the-amount-of-flops-my-computer-is-capable-of
http://stackoverflow.com/questions/15655835/flops-per-cycle-for-sandy-bridge-and-haswell-sse2-avx-avx2

Para calcular cuántos FLOPS se necesita supongo que debe ser fácil. Tú piensa cuántas operaciones tienes que hacer para factorizar dicho número siguiendo el proceso que seguiría un ordenador, supongo, no sé.

EDITO:
En la venerada wikipedia indica que los equipos actuales normalmente tienen una capacidad de 4 FLOPS por ciclo. Esto son 10 GFLOPS.