#2 gracias campeón

#9 ponme algún positivo rońica! (Se cambian por bitcoins en el Menéame premium)

#7 por eso te lo puse. Ahora, como dicen por aquí: "deja de llorar" *y sigue enviando (o descarta) Un saludo

*chiste de aquí, no te lo tomas a mal

#9 ponme algún positivo rońica! (Se cambian por bitcoins en el Menéame premium)

#2 Ya no puedes, sólo lo puedes autodescartar si no está descartada por votos. Para la próxima

#4 ni soy@admin, ni nada parecido, pero juraría que dos admins sí te han votado negativo.

En el momento que la enviaste tenías 4 noticias enviadas y de esa URL dos. Eso es un 50%, Spam.

Ahora que has enviado una más (5 enviadas) de esa web has enviado el 40% de noticias: spam.

Es más, la primera que enviaste fué de allí (que además fue portada, de lo cual me alegro, por cierto)

No existe un término claro para el spam (en números) pero sí te aseguro que eso es spam. Si tiene alguna duda puedes preguntarlo en el Nótame o en la Fisgona.

Sobre el autobombo/spam y para evitar errores, el abuso de fuentes también se vota como spam.

Si envías casi todo el El País (aunque te conozca y sepa que trabajas en el ABC, también se/te votaría como spam: abuso de fuentes.

Lee el link que te puse, más el de Comenzando (Google: "Menéame comenzando") donde te lo explican mejor.

#7 por eso te lo puse. Ahora, como dicen por aquí: "deja de llorar" *y sigue enviando (o descarta) Un saludo

*chiste de aquí, no te lo tomas a mal

#9 ponme algún positivo rońica! (Se cambian por bitcoins en el Menéame premium)

#16 vamos, para una CPU k cumpla con los mismos requisitos de la prueba? Pues eso: humo¡

#8 #28 #29 Yo no soy teleco, pero a mí hay algo que me escama: ¿cuántos ciclos de reloj tarda la CPU en descifrar una sola vez la clave de la víctima? Si el micrófono captura hasta 150KHz, supongo que al menos sampleará hasta 300KHz (Nyquist-Shannon). Si ponemos que el reloj sea de 1GHz nos da una frecuencia 3000 veces mayor que la más pequeña que es capaz de capturar el micrófono.

Vale que dicen que se repite el proceso miles de veces, pero no veo claro que el postproceso intensivo pueda extraer información con un subsampleo tan salvaje. Se podría pensar que de una vez a otra se está sampleando lo mismo, pero eso entra en la situación ideal de que no haya absolutamente nada de ruido de otro tipo. No obstante aunque se repita 2000 veces y se obtuviesen sampleos desfasados de modo que resultase un muestreo más o menos uniformemente equiespaciado (demasiado ideal), aún habría casi el doble de ciclos de reloj. Y todo esto suponiendo que el chequeo de la clave se realice en serie... supongo que en una CPU de 64 bits pasará varios elementos de la clave a la vez....

Es cierto que ellos son conscientes porque en el propio título del paper indican que es "low-bandwidth" y algo más contarán porque sólo lo he ojeado un poco por encima... ¿este artículo lo ha revisado alguien realmente experto en el tema? Lo digo porque la fecha que pone es de ayer...

No digo que no pueda ser posible, sólo me muestro escéptico, pero el resumen de la noticia no da la clave de dónde reside realmente el truco, que son los que se debían haber leído el paper en detalle antes de divulgar en vez de soltar lo que dice el abstract y poco más.

#77 tampoco me parece a mí de buen gusto cuestionarnos a todos de esa forma.

#80 A mi me gustaria que un porcentaje mayor de los comentarios de meneame fuesen "cuestionados de esa forma" tan bien argumentada como la de #77.

#77 El ruido que se capta de la electrónica casi siempre son subarmónicos. De esta manera algo a 3GHz, genera sonido a frecuencias muy por debajo de 3GHz (a las frecuencias f x 1/número primo por debajo y f x número primo por encima). La intensidad y cantidad depende del material, forma de onda...

Además los ordenadores usan ondas cuadradas que son una suma de infinidad de ondas senoidales de distintas frecuencias, superiores e inferiores a la frecuencia base.

Por tanto no solo pudes oir la frecuencia base.

#85 Sí, evidentemente el sonido son vibraciones transmitidas al aire por algo que vibra y a 3Ghz la amplitud de vibración es absolutamente minúscula pues de lo contrario consumiría una energía brutal. El ruido en efecto proviene de excitar los modos de vibración de algún elemento en frecuencias más bajas en plan "aliasing", pero en ese proceso se pierde información y no se explica cómo se extrae de esa medida secundaria (que como comenté en #77 me parece dudoso a falta de más explicación) o de si la correlación entre lo que se captura y los bits interesantes realmente viene por otro lado más que no simplemente "la vibración de la CPU".

De este modo también se podría extraer información de lo que emite un móvil (del orden de GHz) a base de mandarle tropecientos whatsapp (por decir algo) y apuntándole con un micrófono... personalmente necesito más explicaciones y lamentablemente no creo que tenga tiempo de leerme las decenas de hojas del paper de lo que no soy experto y tardaría 100 veces más que el experto que pretendo que lo revise por mí y me lo resuma en la noticia de divulgación, en vez de poner el título y "ahí tienes el paper..."

#77 Aparte de la dificultad del resto, eso es una de las cosas que no me cuadra. Tambien la parte de la transmision del sonido y las captacion del microfono a frecuencias tan altas. A 3ghz no le daria tiempo a moverse mecanicamente supongo. Tal vez el microfono capte algun campo electromagnetico aunque este diseñado para captar sonido "mecanico"

Esto me sonaba que se parecia a un ataque TEMPEST, pero creo que la definicion tambien lo incluiria.
http://blog-trasnadas.blogspot.com.es/2012/11/ataques-tempest.html


#32 Como los mecanicos de antes.
Es algo que llevo pensado desde hace mucho tiempo. En en el sistema educativos se aprende con libro, pero no se educan los sentidos. He oido quejas de que los medicos ahora tienen menos ojo clinico que antes, no se si es cierto o no y no veo que puede haber cambiado a peor para los medicos no adquieran esas habilidades.

Antes era mas dificil enseñarlos y se aprendian una vez trabajando. Pero hoy en dia hay muchos recursos multimedia asequibles, yo creo se podrian enseñar en las capacidades sensoriales.
El olor lo veo mas complicado, pero un sentido muy util por ejemplo, para diagnosticar un fallo motor por el olor que produce o un si un billete es falso. No lo he oido nunca en la tele cuando dan consejos, pero un billete de verdad huele diferente que cualquier otra cosa impresa.

#29 #48 #69 y demás.. No han roto RSA como tal, han roto la seguridad de GnuPG en varias computadoras con procesadores conocidos, que no es lo mismo, por lo que he leído se aprovechan de que saben qué operaciones en concreto está usando la CPU, ya que GnuPG es código abierto, y del sonido que hace la CPU al ejecutarlas, si tu fueses capaz de hacerte una CPU ad-hock, y cambiases el código de GnuPG para tu uso personal (sin llegar a publicarlo) de forma que no fuesen exáctamente las mismas instrucciones, este ataque no funcionaría, no por otra cosa que por no estar dirigido a romper RSA, sino a romper la seguridad del sistema (que no es lo mismo), con esta técnica sólo puedes hacerlo en condiciones ideales, con el ordenador del uno de los interlocutores muy cerca, conociendo qué instrucciones va a ejecutar para cifrarlo/descifrarlo y en qué plataforma lo hará, pero si pillas un mensaje RSA por ahí, sin un ordenador descifrandolo cerca, con este método no lo podrías romper.

Fijáos si es así, que en el mismo paper dice que exáctamente el mismo ataque vale para ElGamal, que no es RSA (aunque también logaritmo discreto, y se parecen mucho), pero me atrevería a más, a decir que con premisas así, no hay algoritmo que se salve, porque no han roto RSA, han roto el sistema de seguridad que lo albergaba en esas situaciones.

Es original, es efectivo, y es serio, pero no considero que sea romper RSA propiamente dicho

#91 La cosa no tiene nada que ver con que el código fuente de GnuPG esté disponible. Las operaciones que realiza RSA como algoritmo son siempre las mismas independientemente de lo que haya alrededor del algoritmo, es decir, que salvo que te hagas tu propia versión de RSA (probablemente estropeándolo), eres susceptible del ataque. De hecho incluso aunque hicieses una CPU ad-hoc como tú dices serías vulnerable al ataque, puesto que se trata de análisis estadísticos.

No han roto nada, "sólo" han explotado un canal encubierto que no se había utilizado antes (qué sepamos) en un entorno controlado (GnuPG).

#93 En lo de el código disponible tienes razón, se puede hacer de otra forma de manera que aunque conocieses el código de GnuPg no te valiese de nada, y lo de las modificaciones no me refería a RSA, de él no he hablado, sólo de GnuPG, el programa en sí, y de la CPU, eso depende de lo que modifiques (si por ejemplo incluyo un generador de ruido aleatorio, no). Por lo demás estamos diciendo lo miso, no han roto RSA porque no han atacado a RSA, sólo a GnuPG, sobre ciertas máquinas y en ciertas condiciones, pero este algoritmo no vale para nada, si te dan un mensaje ya cifrado con RSA cuando no tenías "la oreja puesta".

#97 #93 Insisto, el código da igual, han hecho la prueba sobre GnuPG porque era el que daba resultados más "espectaculares" al poder forzarlo a descifrar muchos mensajes, pero la vulnerabilidad radica en el hecho de que los PCs "suenan" distinto al ejecutar distintas operaciones. Y da igual si es código abierto o cerrado mientras utilicen algoritmos de cifrado conocidos.

#104 Del mismo artículo:

For concreteness, our case study focused on a particular cryptographic implementation (that of GnuPG 1.x), chosen ciphertext channel (OpenPGP-encrypted e-mail messages processed by Enigmail), and class of computers (laptops). However, we expect that similar attacks will be feasible for other software, protocols and hardware.

#29 "Mientras haya una diferencia entre procesar 0 y procesar 1"... buff... madre mía, quien necesita leerse el "paper" (como tú dices) eres tú. Pero bueno...

#13 "en un prueba no sabes exactamente los resultados que vas a obtener, por es una prueba.. Vamos que es un paper de investigación" Claroooo, y si quieres te dejo mi reloj de sobremesa, segun escuches de izq-der se obtienen unos datos

#16 vamos, para una CPU k cumpla con los mismos requisitos de la prueba? Pues eso: humo¡

#8 #28 #29 Yo no soy teleco, pero a mí hay algo que me escama: ¿cuántos ciclos de reloj tarda la CPU en descifrar una sola vez la clave de la víctima? Si el micrófono captura hasta 150KHz, supongo que al menos sampleará hasta 300KHz (Nyquist-Shannon). Si ponemos que el reloj sea de 1GHz nos da una frecuencia 3000 veces mayor que la más pequeña que es capaz de capturar el micrófono.

Vale que dicen que se repite el proceso miles de veces, pero no veo claro que el postproceso intensivo pueda extraer información con un subsampleo tan salvaje. Se podría pensar que de una vez a otra se está sampleando lo mismo, pero eso entra en la situación ideal de que no haya absolutamente nada de ruido de otro tipo. No obstante aunque se repita 2000 veces y se obtuviesen sampleos desfasados de modo que resultase un muestreo más o menos uniformemente equiespaciado (demasiado ideal), aún habría casi el doble de ciclos de reloj. Y todo esto suponiendo que el chequeo de la clave se realice en serie... supongo que en una CPU de 64 bits pasará varios elementos de la clave a la vez....

Es cierto que ellos son conscientes porque en el propio título del paper indican que es "low-bandwidth" y algo más contarán porque sólo lo he ojeado un poco por encima... ¿este artículo lo ha revisado alguien realmente experto en el tema? Lo digo porque la fecha que pone es de ayer...

No digo que no pueda ser posible, sólo me muestro escéptico, pero el resumen de la noticia no da la clave de dónde reside realmente el truco, que son los que se debían haber leído el paper en detalle antes de divulgar en vez de soltar lo que dice el abstract y poco más.

#77 tampoco me parece a mí de buen gusto cuestionarnos a todos de esa forma.

#80 A mi me gustaria que un porcentaje mayor de los comentarios de meneame fuesen "cuestionados de esa forma" tan bien argumentada como la de #77.

#77 El ruido que se capta de la electrónica casi siempre son subarmónicos. De esta manera algo a 3GHz, genera sonido a frecuencias muy por debajo de 3GHz (a las frecuencias f x 1/número primo por debajo y f x número primo por encima). La intensidad y cantidad depende del material, forma de onda...

Además los ordenadores usan ondas cuadradas que son una suma de infinidad de ondas senoidales de distintas frecuencias, superiores e inferiores a la frecuencia base.

Por tanto no solo pudes oir la frecuencia base.

#85 Sí, evidentemente el sonido son vibraciones transmitidas al aire por algo que vibra y a 3Ghz la amplitud de vibración es absolutamente minúscula pues de lo contrario consumiría una energía brutal. El ruido en efecto proviene de excitar los modos de vibración de algún elemento en frecuencias más bajas en plan "aliasing", pero en ese proceso se pierde información y no se explica cómo se extrae de esa medida secundaria (que como comenté en #77 me parece dudoso a falta de más explicación) o de si la correlación entre lo que se captura y los bits interesantes realmente viene por otro lado más que no simplemente "la vibración de la CPU".

De este modo también se podría extraer información de lo que emite un móvil (del orden de GHz) a base de mandarle tropecientos whatsapp (por decir algo) y apuntándole con un micrófono... personalmente necesito más explicaciones y lamentablemente no creo que tenga tiempo de leerme las decenas de hojas del paper de lo que no soy experto y tardaría 100 veces más que el experto que pretendo que lo revise por mí y me lo resuma en la noticia de divulgación, en vez de poner el título y "ahí tienes el paper..."

#77 Aparte de la dificultad del resto, eso es una de las cosas que no me cuadra. Tambien la parte de la transmision del sonido y las captacion del microfono a frecuencias tan altas. A 3ghz no le daria tiempo a moverse mecanicamente supongo. Tal vez el microfono capte algun campo electromagnetico aunque este diseñado para captar sonido "mecanico"

Esto me sonaba que se parecia a un ataque TEMPEST, pero creo que la definicion tambien lo incluiria.
http://blog-trasnadas.blogspot.com.es/2012/11/ataques-tempest.html


#32 Como los mecanicos de antes.
Es algo que llevo pensado desde hace mucho tiempo. En en el sistema educativos se aprende con libro, pero no se educan los sentidos. He oido quejas de que los medicos ahora tienen menos ojo clinico que antes, no se si es cierto o no y no veo que puede haber cambiado a peor para los medicos no adquieran esas habilidades.

Antes era mas dificil enseñarlos y se aprendian una vez trabajando. Pero hoy en dia hay muchos recursos multimedia asequibles, yo creo se podrian enseñar en las capacidades sensoriales.
El olor lo veo mas complicado, pero un sentido muy util por ejemplo, para diagnosticar un fallo motor por el olor que produce o un si un billete es falso. No lo he oido nunca en la tele cuando dan consejos, pero un billete de verdad huele diferente que cualquier otra cosa impresa.

#29 #48 #69 y demás.. No han roto RSA como tal, han roto la seguridad de GnuPG en varias computadoras con procesadores conocidos, que no es lo mismo, por lo que he leído se aprovechan de que saben qué operaciones en concreto está usando la CPU, ya que GnuPG es código abierto, y del sonido que hace la CPU al ejecutarlas, si tu fueses capaz de hacerte una CPU ad-hock, y cambiases el código de GnuPG para tu uso personal (sin llegar a publicarlo) de forma que no fuesen exáctamente las mismas instrucciones, este ataque no funcionaría, no por otra cosa que por no estar dirigido a romper RSA, sino a romper la seguridad del sistema (que no es lo mismo), con esta técnica sólo puedes hacerlo en condiciones ideales, con el ordenador del uno de los interlocutores muy cerca, conociendo qué instrucciones va a ejecutar para cifrarlo/descifrarlo y en qué plataforma lo hará, pero si pillas un mensaje RSA por ahí, sin un ordenador descifrandolo cerca, con este método no lo podrías romper.

Fijáos si es así, que en el mismo paper dice que exáctamente el mismo ataque vale para ElGamal, que no es RSA (aunque también logaritmo discreto, y se parecen mucho), pero me atrevería a más, a decir que con premisas así, no hay algoritmo que se salve, porque no han roto RSA, han roto el sistema de seguridad que lo albergaba en esas situaciones.

Es original, es efectivo, y es serio, pero no considero que sea romper RSA propiamente dicho

#91 La cosa no tiene nada que ver con que el código fuente de GnuPG esté disponible. Las operaciones que realiza RSA como algoritmo son siempre las mismas independientemente de lo que haya alrededor del algoritmo, es decir, que salvo que te hagas tu propia versión de RSA (probablemente estropeándolo), eres susceptible del ataque. De hecho incluso aunque hicieses una CPU ad-hoc como tú dices serías vulnerable al ataque, puesto que se trata de análisis estadísticos.

No han roto nada, "sólo" han explotado un canal encubierto que no se había utilizado antes (qué sepamos) en un entorno controlado (GnuPG).

#93 En lo de el código disponible tienes razón, se puede hacer de otra forma de manera que aunque conocieses el código de GnuPg no te valiese de nada, y lo de las modificaciones no me refería a RSA, de él no he hablado, sólo de GnuPG, el programa en sí, y de la CPU, eso depende de lo que modifiques (si por ejemplo incluyo un generador de ruido aleatorio, no). Por lo demás estamos diciendo lo miso, no han roto RSA porque no han atacado a RSA, sólo a GnuPG, sobre ciertas máquinas y en ciertas condiciones, pero este algoritmo no vale para nada, si te dan un mensaje ya cifrado con RSA cuando no tenías "la oreja puesta".

#97 #93 Insisto, el código da igual, han hecho la prueba sobre GnuPG porque era el que daba resultados más "espectaculares" al poder forzarlo a descifrar muchos mensajes, pero la vulnerabilidad radica en el hecho de que los PCs "suenan" distinto al ejecutar distintas operaciones. Y da igual si es código abierto o cerrado mientras utilicen algoritmos de cifrado conocidos.

#104 Del mismo artículo:

For concreteness, our case study focused on a particular cryptographic implementation (that of GnuPG 1.x), chosen ciphertext channel (OpenPGP-encrypted e-mail messages processed by Enigmail), and class of computers (laptops). However, we expect that similar attacks will be feasible for other software, protocols and hardware.

#29 "Mientras haya una diferencia entre procesar 0 y procesar 1"... buff... madre mía, quien necesita leerse el "paper" (como tú dices) eres tú. Pero bueno...

#13 La terminología habitual es que "romper un cifrado" significa obtener el texto en claro sin conocer la clave de antemano.

Mantener la clave en secreto, tanto cuando se está usando como cuando no, es una cuestión igual de vital, pero es un problema distinto.

Magufadas, magufadas everywhere!

c/c: #9 Bastante??, es preparar un entorno para una prueba, así sacas los resultados que quieras

#13 "en un prueba no sabes exactamente los resultados que vas a obtener, por es una prueba.. Vamos que es un paper de investigación" Claroooo, y si quieres te dejo mi reloj de sobremesa, segun escuches de izq-der se obtienen unos datos

#16 vamos, para una CPU k cumpla con los mismos requisitos de la prueba? Pues eso: humo¡

#8 #28 #29 Yo no soy teleco, pero a mí hay algo que me escama: ¿cuántos ciclos de reloj tarda la CPU en descifrar una sola vez la clave de la víctima? Si el micrófono captura hasta 150KHz, supongo que al menos sampleará hasta 300KHz (Nyquist-Shannon). Si ponemos que el reloj sea de 1GHz nos da una frecuencia 3000 veces mayor que la más pequeña que es capaz de capturar el micrófono.

Vale que dicen que se repite el proceso miles de veces, pero no veo claro que el postproceso intensivo pueda extraer información con un subsampleo tan salvaje. Se podría pensar que de una vez a otra se está sampleando lo mismo, pero eso entra en la situación ideal de que no haya absolutamente nada de ruido de otro tipo. No obstante aunque se repita 2000 veces y se obtuviesen sampleos desfasados de modo que resultase un muestreo más o menos uniformemente equiespaciado (demasiado ideal), aún habría casi el doble de ciclos de reloj. Y todo esto suponiendo que el chequeo de la clave se realice en serie... supongo que en una CPU de 64 bits pasará varios elementos de la clave a la vez....

Es cierto que ellos son conscientes porque en el propio título del paper indican que es "low-bandwidth" y algo más contarán porque sólo lo he ojeado un poco por encima... ¿este artículo lo ha revisado alguien realmente experto en el tema? Lo digo porque la fecha que pone es de ayer...

No digo que no pueda ser posible, sólo me muestro escéptico, pero el resumen de la noticia no da la clave de dónde reside realmente el truco, que son los que se debían haber leído el paper en detalle antes de divulgar en vez de soltar lo que dice el abstract y poco más.

#77 tampoco me parece a mí de buen gusto cuestionarnos a todos de esa forma.

#77 El ruido que se capta de la electrónica casi siempre son subarmónicos. De esta manera algo a 3GHz, genera sonido a frecuencias muy por debajo de 3GHz (a las frecuencias f x 1/número primo por debajo y f x número primo por encima). La intensidad y cantidad depende del material, forma de onda...

Además los ordenadores usan ondas cuadradas que son una suma de infinidad de ondas senoidales de distintas frecuencias, superiores e inferiores a la frecuencia base.

Por tanto no solo pudes oir la frecuencia base.

#85 Sí, evidentemente el sonido son vibraciones transmitidas al aire por algo que vibra y a 3Ghz la amplitud de vibración es absolutamente minúscula pues de lo contrario consumiría una energía brutal. El ruido en efecto proviene de excitar los modos de vibración de algún elemento en frecuencias más bajas en plan "aliasing", pero en ese proceso se pierde información y no se explica cómo se extrae de esa medida secundaria (que como comenté en #77 me parece dudoso a falta de más explicación) o de si la correlación entre lo que se captura y los bits interesantes realmente viene por otro lado más que no simplemente "la vibración de la CPU".

De este modo también se podría extraer información de lo que emite un móvil (del orden de GHz) a base de mandarle tropecientos whatsapp (por decir algo) y apuntándole con un micrófono... personalmente necesito más explicaciones y lamentablemente no creo que tenga tiempo de leerme las decenas de hojas del paper de lo que no soy experto y tardaría 100 veces más que el experto que pretendo que lo revise por mí y me lo resuma en la noticia de divulgación, en vez de poner el título y "ahí tienes el paper..."

#77 Aparte de la dificultad del resto, eso es una de las cosas que no me cuadra. Tambien la parte de la transmision del sonido y las captacion del microfono a frecuencias tan altas. A 3ghz no le daria tiempo a moverse mecanicamente supongo. Tal vez el microfono capte algun campo electromagnetico aunque este diseñado para captar sonido "mecanico"

Esto me sonaba que se parecia a un ataque TEMPEST, pero creo que la definicion tambien lo incluiria.
http://blog-trasnadas.blogspot.com.es/2012/11/ataques-tempest.html


#32 Como los mecanicos de antes.
Es algo que llevo pensado desde hace mucho tiempo. En en el sistema educativos se aprende con libro, pero no se educan los sentidos. He oido quejas de que los medicos ahora tienen menos ojo clinico que antes, no se si es cierto o no y no veo que puede haber cambiado a peor para los medicos no adquieran esas habilidades.

Antes era mas dificil enseñarlos y se aprendian una vez trabajando. Pero hoy en dia hay muchos recursos multimedia asequibles, yo creo se podrian enseñar en las capacidades sensoriales.
El olor lo veo mas complicado, pero un sentido muy util por ejemplo, para diagnosticar un fallo motor por el olor que produce o un si un billete es falso. No lo he oido nunca en la tele cuando dan consejos, pero un billete de verdad huele diferente que cualquier otra cosa impresa.

#80 A mi me gustaria que un porcentaje mayor de los comentarios de meneame fuesen "cuestionados de esa forma" tan bien argumentada como la de #77.

#29 #48 #69 y demás.. No han roto RSA como tal, han roto la seguridad de GnuPG en varias computadoras con procesadores conocidos, que no es lo mismo, por lo que he leído se aprovechan de que saben qué operaciones en concreto está usando la CPU, ya que GnuPG es código abierto, y del sonido que hace la CPU al ejecutarlas, si tu fueses capaz de hacerte una CPU ad-hock, y cambiases el código de GnuPG para tu uso personal (sin llegar a publicarlo) de forma que no fuesen exáctamente las mismas instrucciones, este ataque no funcionaría, no por otra cosa que por no estar dirigido a romper RSA, sino a romper la seguridad del sistema (que no es lo mismo), con esta técnica sólo puedes hacerlo en condiciones ideales, con el ordenador del uno de los interlocutores muy cerca, conociendo qué instrucciones va a ejecutar para cifrarlo/descifrarlo y en qué plataforma lo hará, pero si pillas un mensaje RSA por ahí, sin un ordenador descifrandolo cerca, con este método no lo podrías romper.

Fijáos si es así, que en el mismo paper dice que exáctamente el mismo ataque vale para ElGamal, que no es RSA (aunque también logaritmo discreto, y se parecen mucho), pero me atrevería a más, a decir que con premisas así, no hay algoritmo que se salve, porque no han roto RSA, han roto el sistema de seguridad que lo albergaba en esas situaciones.

Es original, es efectivo, y es serio, pero no considero que sea romper RSA propiamente dicho

#91 La cosa no tiene nada que ver con que el código fuente de GnuPG esté disponible. Las operaciones que realiza RSA como algoritmo son siempre las mismas independientemente de lo que haya alrededor del algoritmo, es decir, que salvo que te hagas tu propia versión de RSA (probablemente estropeándolo), eres susceptible del ataque. De hecho incluso aunque hicieses una CPU ad-hoc como tú dices serías vulnerable al ataque, puesto que se trata de análisis estadísticos.

No han roto nada, "sólo" han explotado un canal encubierto que no se había utilizado antes (qué sepamos) en un entorno controlado (GnuPG).

#29 "Mientras haya una diferencia entre procesar 0 y procesar 1"... buff... madre mía, quien necesita leerse el "paper" (como tú dices) eres tú. Pero bueno...

#13 La terminología habitual es que "romper un cifrado" significa obtener el texto en claro sin conocer la clave de antemano.

Mantener la clave en secreto, tanto cuando se está usando como cuando no, es una cuestión igual de vital, pero es un problema distinto.

#11 Hay que ser muy atrevido para llamar magufo al creador del cifrado RSA...