Electrum es tan seguro? SEMILLAS prefabricadas.
01-jun-2019 11:46
#1
|
Me da curiosidad que nadie haya dudado de este tema. Cuando en electrum creas una semilla, no la creas tu, esas 12 palabras te las da el mismo programa, por lo que alguien ha creado esas 12 palabras, POR LO TANTO YA HAY ALGUIEN QUE SABE CUAL ES ESA SEMILLA. Supongo que el programa tendrá un archivo donde tiene apuntados miles de semillas y te da una aleatoria, pero a ese archivo cualquiera puede acceder, y aun no siendo así, el mismo desarrollador del programa lo puede hacer. Por otra parte, deduzco que al ser 12 palabras, cualquier persona se puede inventar una semilla a base de las tipicas palabras que se suelen utilizar, y lo mas provable es que acabe dando con las claves privadas y wallet de alguien que tenga miles de euros ahí metidos. |
01-jun-2019 13:32
#3
| Es Bitcoin realmente seguro? La clave privada está basada en números y letras, cualquiera puede acceder a ver los números y letras. Solo existen 10 números y 23 letras que además solo se usan las 6 primeras. |
01-jun-2019 13:38
#4
|
Electrum es código abierto. https://github.com/spesmilo/electrum Simple: Revisa el código, observa como genera esas claves, si efectivamente es un método seguro y no las almacena/envía a algún servidor. Si le das el visto bueno, puedes hasta compilarlo tú mismo y usarlo con tranquilidad máxima. De todos modos es un programa muy popular, quiero pensar que está más que revisado y auditado. |
Editado: 01-jun-2019 13:40 -
01-jun-2019 19:59
#6
|
Te explico, genera un número aleatorio de 128 o 256 bits, lo pasa por un algoritmo y te da la semilla traducida a palabras. Si no te fias hazlo tu manual, pero no quieras no hacerlo y dudar de que es fiable. Si quieres un número del 1 al 1000 aleatorio y no te fias de random.org inventatelo tu y no te quejes de que random.org te engaña. |
01-jun-2019 20:10
#7
| No tiene un archivo y elige una semilla aleatoria. Lo que hace es que tiene un diccionario entero (pongamos 300.000 palabras, no sé cuantas putas palabras existen) y coge las palabras aleatorias formando una semilla. Y a lo mejor hay 3 semillas con las mismas palabras, pero no el mismo orden. Por lo tanto estadísticamente es más seguro que las contraseñas numéricas/alfanuméricas normales. |
01-jun-2019 20:36
#8
|
Me da curiosidad que nadie haya dudado de este tema.
Cuando en electrum creas una semilla, no la creas tu, esas 12 palabras te las da el mismo programa, por lo que alguien ha creado esas 12 palabras, POR LO TANTO YA HAY ALGUIEN QUE SABE CUAL ES ESA SEMILLA. Supongo que el programa tendrá un archivo donde tiene apuntados miles de semillas y te da una aleatoria, pero a ese archivo cualquiera puede acceder, y aun no siendo así, el mismo desarrollador del programa lo puede hacer. Por otra parte, deduzco que al ser 12 palabras, cualquier persona se puede inventar una semilla a base de las tipicas palabras que se suelen utilizar, y lo mas provable es que acabe dando con las claves privadas y wallet de alguien que tenga miles de euros ahí metidos. Huye. |
01-jun-2019 21:14
#9
|
Te explico, genera un número aleatorio de 128 o 256 bits, lo pasa por un algoritmo y te da la semilla traducida a palabras.
Si no te fias hazlo tu manual, pero no quieras no hacerlo y dudar de que es fiable. Si quieres un número del 1 al 1000 aleatorio y no te fias de random.org inventatelo tu y no te quejes de que random.org te engaña. |
01-jun-2019 21:16
#10
|
No tiene un archivo y elige una semilla aleatoria. Lo que hace es que tiene un diccionario entero (pongamos 300.000 palabras, no sé cuantas putas palabras existen) y coge las palabras aleatorias formando una semilla. Y a lo mejor hay 3 semillas con las mismas palabras, pero no el mismo orden. Por lo tanto estadísticamente es más seguro que las contraseñas numéricas/alfanuméricas normales.
|
01-jun-2019 21:19
#11
|
Eso he pensado mientras escribía la respuesta, iba a desarrollarla un poco más pero de repente he caído en eso. De todas formas, ¿no va acompañado de un user o algo así? O sea, ¿sólo es seed? Es que si es user o id+seed tiene todo el sentido del mundo y es súper seguro pero sólo seed por mucha estadística y por muy difícil que sea que se repita existe la posibilidad. Decir que no trabajo con electrum, sé lo del seed por otras páginas |
01-jun-2019 21:58
#12
|
Las direcciones se generan derivadas del número. Ese número va del 0 a 2^128 (12 palabras) o 2^256 (24 palabras). Si el software quiere te roba, por eso o te fias o lo revisas. |
01-jun-2019 22:58
#13
| Yo no dudo que el software sea etico y no tenga una puerta trasera para robarte pero si alguien hackea los servidores de Electrum puede hacerse con la private key o la semilla de alquien que haya realizado una transaccion |
01-jun-2019 23:10
#14
| No, no puede. Lo que si pueden hacer es sustituir el software y que te dé las palabras que ellos quieren. Que no sean aleatorias.y ha pasado ya. Pero el.software correcto no hace eso, son aleatorias. |
01-jun-2019 23:36
#16
Claro que existe, el comando random se puede usar en todos los lenguajes de programación
|
01-jun-2019 23:49
#18
|
Supongo que el sarcasmo lo has iniciado tu diciendo que la "aleatoriedad no existe en informática" Si has leido bien mi comentario anterior yo no he dicho que el problema este en la generacion de la semilla. El problema puede estar cuando firmas una transaccion ya que esta pasa por el servidor de Electrum y por lo tanto tu private key. Sin dudar de la buena fe del equipo de Electrum, el servidor puede estar comprometido, pero tambien puede estar comprometido tu movil o PC. |
02-jun-2019 00:48
#19
|
Obviamente el servidor no sabe ni accede a tu clave ni puede robarte. |
02-jun-2019 00:51
#20
|
El procesador y los algoritmos son deterministicos y predecibles, la fuente de aleatoriedad no*. (Ejemplo: tiempo de respuesta del hdd, tiempo de llegada de los paquetes de red y un largo etc). *Me refiero a que es imposible de determinar para un observador externo sin control del ordenador. Pues aunque emitas tu los paquetes el cable y tarjeta de red agregan latencia, etc etc. Electrum creo que usa también el movimiento del ratón que es introducido por el usuario por lo que es aleatorio también. --- RECUERDO que para predecir el número aleatorio necesitas saber TODAS las fuentes de aleatoriedad A LA VEZ. En 2005 Windows sacaba la entropía de: The RNG generates as specified in FIPS 186-2 appendix 3.1 with SHA-1 as the G function. With entropy from: The current process ID (GetCurrentProcessID). The current thread ID (GetCurrentThreadID). The ticks since boot (GetTickCount). The current time (GetLocalTime). Various high-precision performance counters (QueryPerformanceCounter). An MD4 hash of the user’s environment block, which includes username, computer name, and search path. MD4 is a hashing algorithm that creates a 128-bit message digest from input data to verify data integrity. High-precision internal CPU counters, such as RDTSC, RDMSR, RDPMC Low-level system information: Idle Process Time, Io Read Transfer Count, I/O Write Transfer Count, I/O Other Transfer Count, I/O Read Operation Count, I/O Write Operation Count, I/O Other Operation Count, Available Pages, Committed Pages, Commit Limit, Peak Commitment, Page Fault Count, Copy On Write Count, Transition Count, Cache Transition Count, Demand Zero Count, Page Read Count, Page Read I/O Count, Cache Read Count, Cache I/O Count, Dirty Pages Write Count, Dirty Write I/O Count, Mapped Pages Write Count, Mapped Write I/O Count, Paged Pool Pages, Non Paged Pool Pages, Paged Pool Allocated space, Paged Pool Free space, Non Paged Pool Allocated space, Non Paged Pool Free space, Free System page table entry, Resident System Code Page, Total System Driver Pages, Total System Code Pages, Non Paged Pool Lookaside Hits, Paged Pool Lookaside Hits, Available Paged Pool Pages, Resident System Cache Page, Resident Paged Pool Page, Resident System Driver Page, Cache manager Fast Read with No Wait, Cache manager Fast Read with Wait, Cache manager Fast Read Resource Missed, Cache manager Fast Read Not Possible, Cache manager Fast Memory Descriptor List Read with No Wait, Cache manager Fast Memory Descriptor List Read with Wait, Cache manager Fast Memory Descriptor List Read Resource Missed, Cache manager Fast Memory Descriptor List Read Not Possible, Cache manager Map Data with No Wait, Cache manager Map Data with Wait, Cache manager Map Data with No Wait Miss, Cache manager Map Data Wait Miss, Cache manager Pin-Mapped Data Count, Cache manager Pin-Read with No Wait, Cache manager Pin Read with Wait, Cache manager Pin-Read with No Wait Miss, Cache manager Pin-Read Wait Miss, Cache manager Copy-Read with No Wait, Cache manager Copy-Read with Wait, Cache manager Copy-Read with No Wait Miss, Cache manager Copy-Read with Wait Miss, Cache manager Memory Descriptor List Read with No Wait, Cache manager Memory Descriptor List Read with Wait, Cache manager Memory Descriptor List Read with No Wait Miss, Cache manager Memory Descriptor List Read with Wait Miss, Cache manager Read Ahead IOs, Cache manager Lazy-Write IOs, Cache manager Lazy-Write Pages, Cache manager Data Flushes, Cache manager Data Pages, Context Switches, First Level Translation buffer Fills, Second Level Translation buffer Fills, and System Calls. System exception information consisting of Alignment Fix up Count, Exception Dispatch Count, Floating Emulation Count, and Byte Word Emulation Count. System lookaside information consisting of Current Depth, Maximum Depth, Total Allocates, Allocate Misses, Total Frees, Free Misses, Type, Tag, and Size. System interrupt information consisting of context switches, deferred procedure call count, deferred procedure call rate, time increment, deferred procedure call bypass count, and asynchronous procedure call bypass count. System process information consisting of Next Entry Offset, Number Of Threads, Create Time, User Time, Kernel Time, Image Name, Base Priority, Unique Process ID, Inherited from Unique Process ID, Handle Count, Session ID, Page Directory Base, Peak Virtual Size, Virtual Size, Page Fault Count, Peak Working Set Size, Working Set Size, Quota Peak Paged Pool Usage, Quota Paged Pool Usage, Quota Peak Non Paged Pool Usage, Quota Non Paged Pool Usage, Page file Usage, Peak Page file Usage, Private Page Count, Read Operation Count, Write Operation Count, Other Operation Count, Read Transfer Count, Write Transfer Count, and Other Transfer Count. |
Editado: 02-jun-2019 00:58 -
02-jun-2019 02:40
#21
|
A ver, un ordenador genera números aleatorios, esos números se traducen a palabras para que el humano lo apunte mas fácilmente, internamente se trabaja con el número.
Las direcciones se generan derivadas del número. Ese número va del 0 a 2^128 (12 palabras) o 2^256 (24 palabras). Si el software quiere te roba, por eso o te fias o lo revisas. Me estás diciendo que aleatoriamente se generan varios números y siempre da la casualdiad que cuando esos números son codificados a letras, justo estas letras hacen combinaciones que dan palabras que EXISTEN??? Lo siento, pero lo que dices no tiene sentido. |
02-jun-2019 02:42
#22
|
No tiene ningún sentido lo que dices. Por favor, razona tu explicación.
Me estás diciendo que aleatoriamente se generan varios números y siempre da la casualdiad que cuando esos números son codificados a letras, justo estas letras hacen combinaciones que dan palabras que EXISTEN??? Lo siento, pero lo que dices no tiene sentido. https://github.com/bitcoin/bips/blob...0039.mediawiki Esa es la especificación original, la definición del que inventó el sistema. |
02-jun-2019 02:44
#23
| Madre mia acabas de echar por tierra años de criptografía. Que tiemble chema alonso |
02-jun-2019 02:45
#24
|
El procesador y los algoritmos son deterministicos y predecibles, la fuente de aleatoriedad no*. (Ejemplo: tiempo de respuesta del hdd, tiempo de llegada de los paquetes de red y un largo etc).
*Me refiero a que es imposible de determinar para un observador externo sin control del ordenador. Pues aunque emitas tu los paquetes el cable y tarjeta de red agregan latencia, etc etc. Electrum creo que usa también el movimiento del ratón que es introducido por el usuario por lo que es aleatorio también. --- RECUERDO que para predecir el número aleatorio necesitas saber TODAS las fuentes de aleatoriedad A LA VEZ. En 2005 Windows sacaba la entropía de: The RNG generates as specified in FIPS 186-2 appendix 3.1 with SHA-1 as the G function. With entropy from: The current process ID (GetCurrentProcessID). The current thread ID (GetCurrentThreadID). The ticks since boot (GetTickCount). The current time (GetLocalTime). Various high-precision performance counters (QueryPerformanceCounter). An MD4 hash of the user’s environment block, which includes username, computer name, and search path. MD4 is a hashing algorithm that creates a 128-bit message digest from input data to verify data integrity. High-precision internal CPU counters, such as RDTSC, RDMSR, RDPMC Low-level system information: Idle Process Time, Io Read Transfer Count, I/O Write Transfer Count, I/O Other Transfer Count, I/O Read Operation Count, I/O Write Operation Count, I/O Other Operation Count, Available Pages, Committed Pages, Commit Limit, Peak Commitment, Page Fault Count, Copy On Write Count, Transition Count, Cache Transition Count, Demand Zero Count, Page Read Count, Page Read I/O Count, Cache Read Count, Cache I/O Count, Dirty Pages Write Count, Dirty Write I/O Count, Mapped Pages Write Count, Mapped Write I/O Count, Paged Pool Pages, Non Paged Pool Pages, Paged Pool Allocated space, Paged Pool Free space, Non Paged Pool Allocated space, Non Paged Pool Free space, Free System page table entry, Resident System Code Page, Total System Driver Pages, Total System Code Pages, Non Paged Pool Lookaside Hits, Paged Pool Lookaside Hits, Available Paged Pool Pages, Resident System Cache Page, Resident Paged Pool Page, Resident System Driver Page, Cache manager Fast Read with No Wait, Cache manager Fast Read with Wait, Cache manager Fast Read Resource Missed, Cache manager Fast Read Not Possible, Cache manager Fast Memory Descriptor List Read with No Wait, Cache manager Fast Memory Descriptor List Read with Wait, Cache manager Fast Memory Descriptor List Read Resource Missed, Cache manager Fast Memory Descriptor List Read Not Possible, Cache manager Map Data with No Wait, Cache manager Map Data with Wait, Cache manager Map Data with No Wait Miss, Cache manager Map Data Wait Miss, Cache manager Pin-Mapped Data Count, Cache manager Pin-Read with No Wait, Cache manager Pin Read with Wait, Cache manager Pin-Read with No Wait Miss, Cache manager Pin-Read Wait Miss, Cache manager Copy-Read with No Wait, Cache manager Copy-Read with Wait, Cache manager Copy-Read with No Wait Miss, Cache manager Copy-Read with Wait Miss, Cache manager Memory Descriptor List Read with No Wait, Cache manager Memory Descriptor List Read with Wait, Cache manager Memory Descriptor List Read with No Wait Miss, Cache manager Memory Descriptor List Read with Wait Miss, Cache manager Read Ahead IOs, Cache manager Lazy-Write IOs, Cache manager Lazy-Write Pages, Cache manager Data Flushes, Cache manager Data Pages, Context Switches, First Level Translation buffer Fills, Second Level Translation buffer Fills, and System Calls. System exception information consisting of Alignment Fix up Count, Exception Dispatch Count, Floating Emulation Count, and Byte Word Emulation Count. System lookaside information consisting of Current Depth, Maximum Depth, Total Allocates, Allocate Misses, Total Frees, Free Misses, Type, Tag, and Size. System interrupt information consisting of context switches, deferred procedure call count, deferred procedure call rate, time increment, deferred procedure call bypass count, and asynchronous procedure call bypass count. System process information consisting of Next Entry Offset, Number Of Threads, Create Time, User Time, Kernel Time, Image Name, Base Priority, Unique Process ID, Inherited from Unique Process ID, Handle Count, Session ID, Page Directory Base, Peak Virtual Size, Virtual Size, Page Fault Count, Peak Working Set Size, Working Set Size, Quota Peak Paged Pool Usage, Quota Paged Pool Usage, Quota Peak Non Paged Pool Usage, Quota Non Paged Pool Usage, Page file Usage, Peak Page file Usage, Private Page Count, Read Operation Count, Write Operation Count, Other Operation Count, Read Transfer Count, Write Transfer Count, and Other Transfer Count. Si un ordenador tuvieese toda esta información podríamos saber en que numero caeria. |
02-jun-2019 02:51
#25
|
No os ralléis. La aleatoriedad no existe ni en la vida real. En la ruleta mismamente, la bola cae al 3 por acción del impulso mas millones de factores que intervienen en el movimiento de la bola, gravedad, aire, oxigeno, terreno, microterreno, etc...
Si un ordenador tuvieese toda esta información podríamos saber en que numero caeria. Si tienes el control de la máquina puedes extraer directamente la clave privada sin hacer nada con numeros aleatorios. Igual que una ruleta es impredecible para un observador humano. El otro debate es filosófico pero en la práctica a no afecta en nada. |
04-jun-2019 23:42
#26
|
Leelo y vale:
https://github.com/bitcoin/bips/blob...0039.mediawiki Esa es la especificación original, la definición del que inventó el sistema. Lo dice ahí. Primero escoge las palabras y las convierte luego. |
05-jun-2019 07:08
#27
![]() https://github.com/bitcoin/bips/blob...g-the-mnemonic Generating the mnemonic The mnemonic must encode entropy in a multiple of 32 bits. With more entropy security is improved but the sentence length increases. We refer to the initial entropy length as ENT. The allowed size of ENT is 128-256 bits. First, an initial entropy of ENT bits is generated. A checksum is generated by taking the first ENT / 32 bits of its SHA256 hash. This checksum is appended to the end of the initial entropy. Next, these concatenated bits are split into groups of 11 bits, each encoding a number from 0-2047, serving as an index into a wordlist. Finally, we convert these numbers into words and use the joined words as a mnemonic sentence. The following table describes the relation between the initial entropy length (ENT), the c |
05-jun-2019 07:39
#28
|
Supongo que el sarcasmo lo has iniciado tu diciendo que la "aleatoriedad no existe en informática"
Si has leido bien mi comentario anterior yo no he dicho que el problema este en la generacion de la semilla. El problema puede estar cuando firmas una transaccion ya que esta pasa por el servidor de Electrum y por lo tanto tu private key. Sin dudar de la buena fe del equipo de Electrum, el servidor puede estar comprometido, pero tambien puede estar comprometido tu movil o PC. Lo que si se envia (y queda en el blockchain, es decir a la vista de todos) es la clave publica, para verificar que la dirección te pertenece (la dirección es el hash de la clave publica). Sacar la clave privada a partir de la publica no es viable a dia de hoy. En eso se basa prácticamente TODA la seguridad informática que existe. Certificados digitales, SSL, etc se basa en eso, no solo el Bitcoin. Y aun cuando un ordenador cuantico sea capaz en el futuro, primero tendria que sacar la clave publica a partir del hash, es una medida adicional de protección (los ordenadores cuanticos son buenos para romper criptografía asimétrica de clave publica / privada, pero no para hallar colisiones en los hashes). Recién revelas la clave publica cuando emites una transacción, asi que un atacante tendria unos pocos minutos para sacar la clave privada de la publica antes que la transacción quede registrada en el blockchain (y después de la transacción la dirección queda vacia SIEMPRE, si luego no vuelves a recibir nada alli, como se recomienda, esa dirección ya no se vuelve a usar). |
05-jun-2019 09:21
#29
|
La aleatoriedad (entropía) absoluta es muy difícil de encontrar incluso en la naturaleza. Medir la descomposición de partículas radioactivas es de las pocas cosas que se consideran una fuente de entropía “verdadera”. https://sites.google.com/site/astudy...ioactive-decay Como curiosidad, en el año 1955 se publicó un libro solo con números pseudo aleatorios para ser usadas en distintas aplicaciones que lo requerían… https://en.wikipedia.org/wiki/A_Mill...ormal_Deviates Existen aparatos que se conectan a un ordenador y le proporcionan lecturas de descomposición radioactiva ambiental, para añadir “entropía real”. Un PC doméstico no tiene eso, pero recibe entropía externa de los sensores que tiene entre otras cosas (temperatura, ventiladores, voltajes, etc). Así que sí, un ordenador no puede generar números puramente aleatorios, pero tiene esas fuentes de entropía para generar números “pseudo aleatorios” que son más que suficientes para tareas criptográficas. Otra curiosidad, los ordenadores tienen dos formas de generar números pseudo aleatorios. Una es a través de “la hora” y va bien para tareas no criptográficas, por ejemplo si simulas un dado, un balanceo de carga o cosas por el estilo. En .NET (Windows) por ejemplo es la clase “System.Random”, y en Linux es “/dev/urandom” (este último genera números aleatorios usando entropía externa pero si se solicitan más números aleatorios de los que es capaz de generar con la entropía que “entra”, los generara sin ella, solo con la hora y demás, con lo cual no garantiza que esos números pseudo aleatorios se puedan usar para tareas criptográficas). Luego tiene un pool de entropía que se usa para generar números pseudo aleatorios criptográficamente seguros. En Linux es “/dev/random” (si se queda sin entropía, deja de generara números pseudo aleatorios y espera que vuelva a entrar entropía, así que sí es una fuente confiable de números pseudo aleatorios criptográficamente seguros) y en .NET es “System.Security.Cryptography. RNGCryptoServiceProvider”. Ni que decir tiene que Electrum y cualquier wallet decente usa números pseudo aleatorios generados mediante el pool de entropía y son criptográficamente seguros. Podeis comprobar el código fuente para comprobarlo. Existen ataques teóricos ("entropy pool exhaustion", se llaman) consistentes en generar muchos números de estos para “agotar” el pool de entropía (mitigados si se usa /dev/random como comente antes) y así que los números generados no sean criptográficamente seguros. Pero son muy muy complejos y requieren acceso total a la máquina. En la práctica si tienes un virus/troyano, lo que harán será dejar que generes la semilla, la capturen y la manden al “atacante”, así que no vale la pena hacerse pajas mentales con este tema… Por cierto lo de las 12 palabras... Esas doce palabras es un sistema mnemotécnico, hecho para que sea fácil de recordar. No significa que las 12 palabras estén asignadas con anterioridad, ni mucho menos. Significa que tu haces una asignación, en plan “El 1 es la palabra “casa”, el 2 es la palabra “hamburguesa”, el 3…” así hasta 1000 por ejemplo. Entonces, si generas un número de 1 a 999.999, lo divides en dos grupos de 1000 y usas la palabra asignada. Es mucho más fácil de recordar “coche mesa” que 746.568, verdad? Pues es lo mismo porque 746 se le asigno la palabra “coche” y a 568 se le asigno “mesa”. Y el 1002 sería “casa hamburguesa”. Las palabras asignadas no tienen nada que ver con haber generado un número de forma aleatoria, que es a lo que se refiere el BIP. Sobre colisiones y poder generar una cartera generada anteriormente: las posibilidades son remotas. Es más fácil que te toque el premio gordo de la lotería. 3 veces seguidas. Con el BIP39 tienes 2^128 posibilidades reales, es decir un 3 * 10^38 (38 ceros). Si quieres puedes intentarlo, si tienes suerte encontrarás una cartera llena de bitcoins. En ese caso avísanos desde tu yate. Pero te adelanto que vas a perder el tiempo, anda que no hay gente que lleva intentándolo desde hace años... y ahí siguen…
|
SIEMPRE CONFIÉ EN EL CLEB.
