Topic: Son seguros los monederos de papel ? - page 2. (Read 5344 times)

Gracias Luiscar por la respuest, pero esto es muy nuevo para mi y no se nada de criptografía, estoy recien ahora leyendo algo para introducirme en el funcionamiento de bitcoin.

En blockchain.info veo dos número (por ejemplo el link que puse arriba), por lo que me decis son direcciónes, no claves publicas, las claves públicas no se ven, ok. O sea se pasan por funciones hash y se muestran direcciones.

De todas maneras y aca viene la pregunta: ¿unas son direcciónes de salida (las seis del ejemplo que completan la transferencia de 28 btc) y otra es la dirección de entrada?
¿Es correcto?

Gracias!

Es un concepto criptográfico, pero dirección bitcoin es distinto de clave pública. La dirección bitcoin la obtenemos de la clave pública tras pasar esta última por unas funciones hash.

eso es una tontería yo lo digo por seguridad pues el equipo siempre se debe considerar zona hostil. Nadie va reventar el cifrado de curvas elípticas, y si lo hiciesen el sistema no serviría de nada lo bitcoins no valdrían nada

Bien, para terminar de cerrar el concepto, cuando decíamos mas arriba:

... Cuando se hace un pago de una dirección 1a a otra dirección 1b, se publica en la transacción la clave pública de 1a, pero no la de 1b. Esto quiere decir que la red Bitcoin contiene a la vista de todo el mundo las claves públicas de las direcciones que han sido origen de transferencias. Debido a eso, si todo mi saldo se encuentra en direcciones que nunca han sido origen de pagos podré dormir más tranquilo, ya que estoy protegido por la seguridad criptográfica de tres operaciones..

Por ejemplo aca veo ahora en blockchain
https://blockchain.info/es/address/1JLJp8A1T4FCJnbVQ5EgQhyYyhi1E1M3iD

Transferencias de 28 btc a cierta cuenta.
Los btc salen de 6 seis direcciones y van a 1 una sola.
Sin embargo blockchain muestra las direcciones origen 6 (seis) y la dirección destino ¿o estoy entendiendo mal algo?

Como las direcciones de papel solo se deben usar una vez por seguridad, necesitas otra dirección donde trasferir el resto del dinero.
Pongamos por ejemplo, que tengo que hacer un pago de 0.5 BTC, pues el resto, los otros 0.5 BTC, los transfieres a otra dirección que no hubieses usado. Si la cantidad sobrante es pequeña, no es necesario trasferirlo a otra y la puedes dejar en el monedero online.

Gracias por la respuesta haztecoin, si me permitis y no es abuso ¿para qué las de saldo en 0 cero?

La cantidad es considerable podrías hacer 100 claves de 10 btc y otras 5 de 0 btc. O podrías hacer 10000 de 1 btc.
Cuanto más diversifiques mejor. Lo más importante es que solo las uses una vez.

Una tablita para que quede todo bien ordenado.

dirección A	|saldo	|dirección B	|saldo
1.............	|1BTC	|1......	|0
1.............	|1BTC	|1......	|0
1.............	|1BTC	|1......	|0
1.............	|1BTC	|1......	|0
1.....	|1BTC

Una pregunta, disculpen si no va en este hilo pero está relacionado creo.

Hagamos una suposición que recibo un pago grande, por ejemplo 1.000 BTC (es suposición por ahora no tengo posibilidades de cobrar ese dinero, ja ja)

La pregunta es ¿cuál es la mejor manera de guardarlos? por ej. hacerme 100 claves privadas de 10 btc en papel?

Espero que no sea una pregunta muy tonta.
Gracias!

Entendía que estábamos habando del menor nivel de seguridad que dan las direcciones que se han utilizado para un pago. En eso no hay ninguna diferencia entre Bitcoin y Litecoin. Las dos usan ECDSA, SHA-256 y RIPEMD-160. Y cuando una dirección se ha utilizado en un pago, se pierde la seguridad que añaden estas dos últimas funciones de hash y quedas solo protegido por ECDSA. Supongo que al menos estarás ya de acuerdo con esto. Si no, no entiendo cuál es tu argumento para negarlo.

Lo que estás comentando ahora es otra cuestión diferente, que es la seguridad del sistema de prueba-de-trabajo. Si se descubriera una vulnerabilidad en SHA-256, podría ser necesario cambiar el algoritmo por otro, por ejemplo SHA-3 (o el propio Scrypt de Litecoin si durara más que SHA-256, que lo dudo), y ahí haría falta el consenso para hacer un fork y que a partir de un determinado número de bloque se utilizara SHA-3 para la prueba-de-trabajo. En cualquier caso, las debilidades en los algoritmos de hash se suelen encontrar poco a poco. Es un problema mucho más difícil de tratar que el de encontrar algoritmos para resolver logaritmos discretos y no parece razonable pensar que se vaya a encontrar un algoritmo que con unas pocas operaciones te revele el valor de nonce necesario que junto a unos datos arbitrarios haga que sha-256 devuelva un valor menor de un umbral. Tendría que ser algo así de brutal para que SHA-256 ya no se pudiera utilizar en absoluto. La mayoría de vulnerabilidades imaginables que se puedan encontrar, como algoritmos para producir colisiones, no impedirían seguir utilizándolo durante muchos años hasta el número de bloque en que se pasara a utilizar SHA-3, o lo que sea, para la prueba-de-trabajo. Un hard fork de este tipo no sería para nada el fin de Bitcoin.

El único problema real que supondría el fin de Bitcoin sería que fracasaran todas las primitivas criptográficas coocidas y no se encontaran reemplazos; es decir, que un día no hubiera ninguna función hash segura ni ningún sistema de clave pública segura. Pero en ese caso, morirían todas las aplicaciones de la criptografía.

Quizás se entienda mejor con un ejemplo.
Pongamos que se descubre una vulnerabilidad en el SHA que permita tener el texto necesario a partir del SHA con lo que se eliminaría la necesidad de la fuerza bruta en la minería; En ese momento minar por fuerza bruta seria ridículo y usar el SHA también, entonces la gente empezaría a utilizar otras monedas como Litecoin que no usan el SHA con lo cual empezaría a perder valor el bitcoin y a aumentar el valor de las monedas no afectadas por dicho problema, pues la cadena de bloques quedaría seriamente comprometida, pues uno podría crear una nueva cadena desde el principio mucho más larga que la ya existente anulando toda la cadena

Estamos ya muy off-topic y tal vez sea mejor abrir hilos nuevos (o reflotar antiguos) si queremos continuar discutiendo algunos de estos temas concretos que van saliendo, como el alcance de un ataque del 51%, los peligros de las brainwallets, las consecuencias del tamaño de la cadena de bloques, etc. Comentaré solamente una cosa que ha dicho haztecoin que no veo clara:


Incluso en los escenarios más catastrofistas, no creo que fuera necesario pasarse a otra cadena de bloques diferente. En Bitcoin las salidas de las transacciones llevan una especie de libro de instrucciones que dice las normas que se deben cumplir para liberar esa salida y poder utilizarla como entrada de otra transacción. Esas instrucciones se enuncian mediante un lenguaje de script en el que se usan operaciones codificadas como, por ejemplo, OP_HASH160 u OP_CHECKSIG y ese lenguaje de script se podría extender en el futuro. Esta es una de las partes de Bitcoin que menos conozco, pero entiendo que la adopción de primitivas criptográficas más sofisticadas podría abordarse añadiendo nuevas operaciones para hacer una nueva forma de script estándar más complejo. Además, la eventual necesidad de una criptografía más robusta es uno de los pocos casos en que sería fácil lograr el consenso necesario para hacer un fork. Ahora mismo no hay ninguna criptomoneda que no utilice la misma criptografía de clave elíptica que Bitcoin, por lo que probablemente sería más sencillo hacer algo así desde dentro de Bitcoin y no abandonándola por otra moneda creada ad hoc como reemplazo.

Aparte de eso, creo que cambiar el tamaño de clave utilizado con ECDSA sería igual de problemático que pasarse a un algoritmo totalmente diferente. Bitcoin utiliza una forma concreta de ECDSA con claves de 256 bits y con una curva base concreta (secp256k1). Esto no está parametrizado de ninguna manera, por lo que cambiar a otra curva base con otro tamaño de clave debería tener las mismas implicaciones que un cambio total en la naturaleza del algoritmo.

Supongo que cuando dice diccionario se refería a diccionarios de ataque, que no es lo mismo que el de la RAE.
Estos diccionarios traen un conjunto de claves posibles, el 99 por ciento de las claves que usa la gente se encuentran en esos diccionarios el los cuales se encuentran palabras que no existen como "pk2" o "m0n0" entre otras incluyendo frases mal escritas y populares.

Sólo una puntilla:


y cualquier título o frase de cualquier canción, de libros, tweets, publicaciones en facebook, en foros… (en inglés, sorry!).

Un ataque del 51% sirve para hacer dobles pagos, por ejemplo, pero no puedes "robar" mis bitcoins, creo que no es comparable

No valdrán nada las direcciones reutilizadas. Quienes no reutilizamos direcciones seguiremos teniendo a salvo nuestros bitcoins. De acuerdo que algo así desencadenaría una crisis de confianza en el sistema y seguramente bajaría el valor, pero no tendría por qué ser un golpe mortal.

Además, las primitivas criptográficas no se revientan de la noche a la mañana. Primero habrá avances, bien a través de nuevos algoritmos clásicos o a través de ordenadores cuánticos capaces de aplicar el algoritmo de Shor, que hagan que lo que requería millones de años pase a requerir siglos o décadas. En ese momento, se considerará rota la criptografía de curvas elípticas, pero habrá tiempo para plantear alternativas y seguramente surgirán nuevos algoritmos más seguros (si no, habría que incrementar la longitud de clave, aunque eso sería un parche con problemas de escalabilidad).


Pero ya hay direcciones que son inseguras y que no deben utilizarse. Por ejemplo, cualquier dirección generada por brainwallet.org con un nombre o una palabra que esté en un diccionario común es hoy en día insegura. Si un día pasan a ser inseguras todas las direcciones reutilizadas o todas las direcciones generadas por criptografía de curvas elipticas, simplemente se ampliará el espectro de direcciones que no se deben utilizar y habrá que adoptar nuevos modelos de generación de direcciones. Con un rango de 2¹⁶⁰ valores, siempre habrá direcciones aleatorias de sobra.


Tal vez bastaría con crear nuevos tipos de script para validar las transacciones con otros modelos de criptografía (en su defecto, en curvas elípticas con tamaños de clave mucho mayores).


No. Depende de la complejidad del ataque conocido. Fíjate que si en la generación de direcciones Bitcoin omitiéramos el tercer paso de las operaciones de hash y utilizáramos directamente la clave pública como dirección, tendríamos un par único clave privada/pública mientras que en el modelo existente puede derivarse la misma dirección de un quintillón (!) de pares de clave pública/privada diferentes. Sin embargo, por lo que he comentado en mi mensaje anterior, Bitcoin sería menos seguro si no hubiera esas operaciones de hash.


Eso depende del nivel de popularidad de Bitcoin. A partir de un cierto nivel crítico, del que tal vez estemos ya muy cerca, el ataque del 51% se hace inviable. Y eso es algo que se podrá mantener durante siglos, a diferencia de la seguridad de las primitivas criptográficas, que sí tiene fecha de caducidad. Revisar y fortalecer los algoritmos de hash o el de la firma digital es algo que en algún momento futuro habrá que afrontar con el consenso necesario, mientras que el ataque del 51% es harina de otro costal porque NO es un problema de Bitcoin, sino algo inherente a cuaquier sistema descentralizado. La idea de Bitcoin y de cualquier moneda descentralizada es que el 51% de los nodos (en Bitcoin medidos según el poder computacional) serán honrados. Si no se cumple ese requisito básico, ni Bitcoin ni ningún sistema descentralizado puede funcionar.

Si en algún momento revientan el cifrado de curvas elípticas el bitcoin no valdrá nada.
Una de las peculiaridades es que las direcciones del bitcoin son perpetuas.
En ese caso habría que crear otra moneda que usase un algoritmo no sensible a dicho ataque.
Si una dirección puede crearse con barias claves el echo de que puedas usar más claves para dicha dirección es más inseguro que solo puedas usar una.

De todas maneras esto son cosas irrelevantes pues siempre se pueden atacar por otros lados, el ataque del 51% es mucho más económico y factible que atacar el cifrado de curvas elípticas incluso teniendo millones de transacciones firmadas, o atacar directamente todos los nodos de la red es mucho más fácil que atacar el cifrado teniendo o no la clave publica y con millones de transacciones hechas.

Corrijo una tontería que escribí en mi último mensaje, para que no quede ahí para la posteridad:


Me equivoqué al apuntar en ese breve comentario entre paréntesis, ahora tachado, que sería más "fácil" hacer un ataque de fuerza bruta sobre la dirección que sobre la clave pública. En principio, parecería lógico que así fuera porque las posibles direcciones privadas son 2²⁵⁶ mientras que el total de direcciones son 2¹⁶⁰ (es decir, cada dirección Bitcoin puede ser generada por alrededor de 2⁹⁶ pares diferentes de claves pública y privada). Pero pasé por alto que la seguridad del algoritmo ECDSA de N bits es en realidad de N/2 bits. Esto quiere decir que dada una clave pública de N bits se puede encontrar la clave privada en un máximo de 2^N/2 operaciones. En el caso de Bitcoin, serían 2¹²⁸ intentos, muchos menos que ir probando claves privadas hasta dar con uno de los 2¹⁶⁰ valores posibles de la dirección. Por lo tanto, incluso en el caso de los ataques de fuerza bruta, conocer la clave pública "facilita" las cosas.

Para quienes tengan curiosidad por la explicación matemática, la razón de que basten 2¹²⁸ intentos y no haya que probar uno a uno con todos los casi 2²⁵⁶ posibles valores de la clave privada es la existencia de un algoritmo conocido como "algoritmo del canguro" o "algoritmo lambda" de Pollard, que permite ir avanzando a saltos. La primera vez que vi una mención a ese algoritmo fue en un mensaje de gmaxwell en este foro (https://bitcointalksearch.org/topic/m.1935535). Para más detalles, hay un artículo en la Wikipedia inglesa: http://en.wikipedia.org/wiki/Pollard's_kangaroo_algorithm .

Mi mensaje, al que probablemente haztecoin está respondiendo, se refería a averiguar la privada a partir de las múltiples firmas hechas cuando se hacen múltiples envíos usando la misma clave privada. Por ejemplo, en la transacción d08efb37e631000781a6f118b5741562d26da1d2f358b2ce50d945be2e9021db, la clave privada asociada a la dirección 19GgbRa54uQKkuvpWtajV86BurRuubvk12 se usa 4 veces, para firmar 4 salidas. He aquí las firmas y las claves públicas:


Las firmas son distintas, por supuesto; la clave pública es naturalmente la misma. Ante una hipotética vulnerabilidad de ECDSA que permitiera obtener la clave privada a partir de múltiples firmas hechas con ella, reutilizar direcciones abre la puerta para que te vacíen el monedero.

Las probabilidades de esto tal como está el panorama hoy día son las de siempre, cero coma cero cero cero bla bla bla, pero hay gente haciéndole cosquillas a ECDSA según escribo esto y en cualquier momento puede saltar la liebre.

Supongo que te refieres a que es ridículo que alguien pueda encontrar la clave privada a través de la pública por fuerza bruta (y, además, para eso sería mejor aplicar la fuerza bruta directamente sobre la dirección). Pero no lo es que en los próximos años se pueda descubrir un algoritmo que permita hallar la clave privada con complejidad no exponencial. Otra posibilidad es que se lleguen a construir auténticos ordenadores cuánticos. Creo que ya se conoce una variante del algoritmo cuántico de Shor que permite precisamente hacer ese cálculo inverso de claves ECDSA en tiempo polinomial. En definitiva, la criptografía de curvas elípticas seguramente dejará de ser segura en algún momento futuro.


Es lo mismo en el sentido de que no utilizar direcciones de cambio implica reutilizar direcciones.

Por cierto, me he dado cuenta de que en mi último mensaje olvidé mencionar que la dirección no reutilizada está protegida no por una sino por dos funciones criptográficas, ya que se usa también RIPEMD-160 en el cálculo de la dirección. Esto da un nivel adicional de seguridad, ya que para poder pasar de la dirección a la clave pública habría que romper dos funciones criptográficas, la SHA-256 desarrollada en EE UU y la RIPEMD-160 desarrollada en Europa. A Satoshi no se le pasaba ni una.