Podéis usar los números premiados en la lotería... 
(firmado: alguien que os quiere mangar los fondos)
(firmado: alguien que os quiere mangar los fondos)
Mejor los numeros del google authenticator
Topic: sobre generacion de numeros aleatorios en wallets (Read 1023 times)
Mejor los numeros del google authenticator
Podéis usar los números premiados en la lotería...
(firmado: alguien que os quiere mangar los fondos)
(firmado: alguien que os quiere mangar los fondos)
Igual alguien encontraba un patrón en el peso desigual de los dados al ser del chino... 
El comentario del chino iba específicamente para ver si alguien decía algo
. 
Igual alguien encontraba un patrón en el peso desigual de los dados al ser del chino...
He arrancado Tails por otras cosas así que aquí va:
Editas la línea 6 ("my $rolls = …") para ponerle las tiradas, del 1 al 6. Si pones menos de 99 dígitos, el programa lo rellena por la derecha con 1s (pero eso no es entropía, claro!); si pones más, descarta los extra. A continuación lo transforma en un número en base 6 propiamente dicho (restandole 1 a cada cifra) y luego llama a la utilidad externa bc para transformalo en base 16.
Ni que decir tiene que poner los dedos en las teclas y darle a saco ("41623651365213614236213652") no vale. Sin darte cuenta vas a repetir patrones (había una web monísima para esto pero no me acuerdo). Los dados no hacen eso, por eso hay que usar dados de verdad. Usar este programa y aporrear el teclado es mentirse a uno mismo.
Estos costaron 1 euro en los chinos (pero ya estaban por casa, no los compré para esto). Agitando la caja así tal cual sin abrirla, se obtienen 6 números de golpe.
Code:
#!/usr/bin/perl
use warnings;
use strict;
my $rolls = '123456123456';
my $len_diff = 99 - length $rolls;
if ($len_diff > 0) {
warn "warning: need $len_diff more rolls\n";
$rolls = sprintf '%s%s', $rolls, '1'x$len_diff;
} elsif ($len_diff < 0) {
warn sprintf "warning: discarding %d extra rolls\n", -$len_diff;
$rolls = substr $rolls, 0, 99;
}
$rolls = join '', map { $_ - 1 } split //, $rolls;
print "temp base6 number: $rolls\n";
my $hex = qx{echo 'obase=16; ibase=6; $rolls' |bc}; chomp $hex;
printf "%s%s\n", '0'x(64-length $hex), $hex;
Editas la línea 6 ("my $rolls = …") para ponerle las tiradas, del 1 al 6. Si pones menos de 99 dígitos, el programa lo rellena por la derecha con 1s (pero eso no es entropía, claro!); si pones más, descarta los extra. A continuación lo transforma en un número en base 6 propiamente dicho (restandole 1 a cada cifra) y luego llama a la utilidad externa bc para transformalo en base 16.
Ni que decir tiene que poner los dedos en las teclas y darle a saco ("41623651365213614236213652") no vale. Sin darte cuenta vas a repetir patrones (había una web monísima para esto pero no me acuerdo). Los dados no hacen eso, por eso hay que usar dados de verdad. Usar este programa y aporrear el teclado es mentirse a uno mismo.
Estos costaron 1 euro en los chinos (pero ya estaban por casa, no los compré para esto
). Agitando la caja así tal cual sin abrirla, se obtienen 6 números de golpe. dserrano es cierto que generaste una clave privada tirando dados ?
Lo he dicho por ahí, no? ¿Por qué iba a ser mentira?
como es el proceso?
Ya que insistes… pero antes voy a insertar esto:
tanto te preocupa?
Tiras 99 dados y el resultado es un número en base 6 (con los dígitos del 0 al 5) con 256 y pico bits de información. Lo transformas a base 16 y ya tienes tu clave privada. Después de todo no es más que un número.
No me apetece arrancar el pendrive de Tails para poner el script por aquí, quizá si me entra alguna donación me molesto…
. 
dserrano es cierto que generaste una clave privada tirando dados ?
como es el proceso?
como es el proceso?
alguien un poco mas tecnico podria comentar en que consistio el fallo exactamente ?
Una firma ECDSA (como las que se usan en bitcoin) realizada con una clave privada necesita un número diferente cada vez. No tiene que ser aleatorio, tiene que ser simplemente diferente; sin embargo generarlo aleatoriamente es más fácil que andar siguiéndole la pista al último número que has usado para cada privkey y bla bla, por tanto esto es lo que se suele hacer normalmente. Resumiendo, para firmar necesitas un número aleatorio. Si tu número no es lo suficientemente aleatorio existe el riesgo de que acabes reutilizando alguno anterior (repito, para una privkey dada), y esto se manifiesta visiblemente en la cadena de bloques. El resultado de la firma son dos números, r y s, y r se deriva del número aleatorio de marras (llamado k). Basta con dos firmas hechas con el mismo k para que el resultado comparta el mismo r y, debido a cierta magia matemática que no me he preocupado en entender, tener dos firmas hechas con el mismo r permite recuperar la clave privada.
http://en.wikipedia.org/wiki/Elliptic_Curve_DSA
http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html
el proceso de generacion de aleatoriedad es visto con recelo por muchos programadores.
Generar números aleatorios y tener la seguridad de que lo estás haciendo bien es difícil. ¿Cómo sabes que no hay algún patrón o tendencia por ahí escondidos? Por eso no se suele ver bien que llegue uno e implemente su propio algoritmo, o se ponga a modificar algoritmos de otros.
En general la viabilidad de los algoritmos criptográficos solo se demuestra con el uso y con los años, y ni que decir tiene que deben ser de código abierto para que toda la comunidad les pueda buscar las cosquillas a los algoritmos nuevos que van saliendo. Algoritmos de hash, de cifrado y también de generación de números aleatorios.
algunos sabreis del reciente ataque a localbitcoins en el que parece ser que hubo un usuario del foro seccion habla inglesa que habia advertido meses antes de la posibilidad de un ataque de este tipo , y que acabo perpetrando el mismo, para acabar devolviendo la cantidad levantada y denuciar esta vulnerabilidad, sino recuerdo mal.
alguien un poco mas tecnico podria comentar en que consistio el fallo exactamente ?
alguien un poco mas tecnico podria comentar en que consistio el fallo exactamente ?
No perpetro el ataque, aviso de un incidente previo y cuando volvió a ocurrir, el mismo hacker (johoe aqui en bct) estaba vigilando que no apareciesen valores r duplicados, él recupero los fondos antes que alguien mas lo hiciera sin tan buenas intenciones. Que yo sepa devolvió los fondos a Blockchain.info .
El error en sí es complejo, pero su origen es una falta de aleatoriedad (un valor repetido era reutilizado al generar direcciones) y al final se podían obtener las claves privadas de ciertas direcciones con lo cual se podían robar los fondos.
El error fue provocado por un error de programación, en el cual no se inicializaba una variable antes de usarla, un error que se debería haber descubierto en una auditoria del código.
Por otra parte yo siempre he notado que de esta parte podia existir algun tipo de vulnerabilidad, mismo vescudero en alguna de sus magnificas charlas creo recordar recomendaba usar algun tipo particular de software antes del inicio del proceso de generacion de la semilla de una cartera determinista, para de este modo aumentar la entropia real. (mismo keepas lleva un generador de este tipo).
si esto ocurre es porque el proceso de generacion de aleatoriedad es visto con recelo por muchos programadores.
cuan factible es que un fallo de este tipo pueda afectar a algun monedero?, cuales estarian mas afectados simples, deterministas ?
tambien he leido por ahi dserrano que tu habias generado algun monedero tirando dados, tanto te preocupa?
si esto ocurre es porque el proceso de generacion de aleatoriedad es visto con recelo por muchos programadores.
cuan factible es que un fallo de este tipo pueda afectar a algun monedero?, cuales estarian mas afectados simples, deterministas ?
tambien he leido por ahi dserrano que tu habias generado algun monedero tirando dados, tanto te preocupa?
Crear entropia es un problema muy complejo para un ordenador. Por eso muchos wallets te hacen mover el ratón o entrar algún texto antes de generar números aleatorios. Si hay un error en el software que genera esos números o no se consigue suficiente entropia, las claves generadas pueden seguir un patrón y por tanto ser predecibles y por tanto inseguras.
Visto el reciente ataque a localbitcoins
O te refieres a bc.info o me he perdido algo.
tambien he leido por ahi dserrano que tu habias generado algun monedero tirando dados, tanto te preocupa?
Hombre, esta claro que "cuanto mas real sea la aleatoriedad" mejor, ¿no?
Visto el reciente ataque a localbitcoins blochkchain.info (gracias) y las especulaciones sobre el caso bitstamp me parece interesante abrir este hilo para compartir opiniones de gente mas experta en el tema de la generacion de numeros aleatorios en el proceso de generacion de claves privadas de los monederos bitcoin.
algunos apuntes para abrir :
algunos sabreis del reciente ataque a localbitcoins en el que parece ser que hubo un usuario del foro seccion habla inglesa que habia advertido meses antes de la posibilidad de un ataque de este tipo , y que acabo perpetrando el mismo, para acabar devolviendo la cantidad levantada y denuciar esta vulnerabilidad, sino recuerdo mal.
alguien un poco mas tecnico podria comentar en que consistio el fallo exactamente ?
Por otra parte yo siempre he notado que de esta parte podia existir algun tipo de vulnerabilidad, mismo vescudero en alguna de sus magnificas charlas creo recordar recomendaba usar algun tipo particular de software antes del inicio del proceso de generacion de la semilla de una cartera determinista, para de este modo aumentar la entropia real. (mismo keepas lleva un generador de este tipo).
si esto ocurre es porque el proceso de generacion de aleatoriedad es visto con recelo por muchos programadores.
cuan factible es que un fallo de este tipo pueda afectar a algun monedero?, cuales estarian mas afectados simples, deterministas ?
tambien he leido por ahi dserrano que tu habias generado algun monedero tirando dados, tanto te preocupa?
algunos apuntes para abrir :
algunos sabreis del reciente ataque a localbitcoins en el que parece ser que hubo un usuario del foro seccion habla inglesa que habia advertido meses antes de la posibilidad de un ataque de este tipo , y que acabo perpetrando el mismo, para acabar devolviendo la cantidad levantada y denuciar esta vulnerabilidad, sino recuerdo mal.
alguien un poco mas tecnico podria comentar en que consistio el fallo exactamente ?
Por otra parte yo siempre he notado que de esta parte podia existir algun tipo de vulnerabilidad, mismo vescudero en alguna de sus magnificas charlas creo recordar recomendaba usar algun tipo particular de software antes del inicio del proceso de generacion de la semilla de una cartera determinista, para de este modo aumentar la entropia real. (mismo keepas lleva un generador de este tipo).
si esto ocurre es porque el proceso de generacion de aleatoriedad es visto con recelo por muchos programadores.
cuan factible es que un fallo de este tipo pueda afectar a algun monedero?, cuales estarian mas afectados simples, deterministas ?
tambien he leido por ahi dserrano que tu habias generado algun monedero tirando dados, tanto te preocupa?
Jump to: