Marek Palatinus JustCryptoNews

Minimizing Trust in Hardware Wallets with Two Factor Signatures

Cryptology ePrint Archive: Report 2019/006
Date: 2019-01-02
Author(s): Antonio Marcedone, Rafael Pass, abhi shelat

Link to Paper

We introduce the notion of two-factor signatures (2FS), a generalization of a two-out-of-two threshold signature scheme in which one of the parties is a hardware token which can store a high-entropy secret, and the other party is a human who knows a low-entropy password. The security (unforgeability) property of 2FS requires that an external adversary corrupting either party (the token or the computer the human is using) cannot forge a signature. This primitive is useful in contexts like hardware cryptocurrency wallets in which a signature conveys the authorization of a transaction. By the above security property, a hardware wallet implementing a two-factor signature scheme is secure against attacks mounted by a malicious hardware vendor; in contrast, all currently used wallet systems break under such an attack (and as such are not secure under our definition). We construct efficient provably-secure 2FS schemes which produce either Schnorr signature (assuming the DLOG assumption), or EC-DSA signatures (assuming security of EC-DSA and the CDH assumption) in the Random Oracle Model, and evaluate the performance of implementations of them. Our EC-DSA based 2FS scheme can directly replace currently used hardware wallets for Bitcoin and other major cryptocurrencies to enable security against malicious hardware vendors.

[1] Jes´us F Almansa, Ivan Damg˚ard, and Jesper Buus Nielsen. Simplified threshold RSA with adaptive and proactive security. In Eurocrypt, volume 4004, pages 593–611. Springer, 2006.
[2] Dan Boneh, Xuhua Ding, Gene Tsudik, and Chi-Ming Wong. A method for fast revocation of public key certificates and security capabilities. In USENIX Security Symposium, pages 22–22, 2001.
[3] Jan Camenisch, Anja Lehmann, Gregory Neven, and Kai Samelin. Virtual smart cards: how to sign with a password and a server, 2016.
[4] Yvo Desmedt and Yair Frankel. Threshold cryptosystems. In Advances in Cryptology – CRYPTO 1989, pages 307–315. Springer, 1990.
[5] J. Doerner, Y. Kondi, E. Lee, and a. shelat. Secure two-party threshold ECDSA from ECDSA assumptions. In 2018 IEEE Symposium on Security and Privacy (SP), pages 595–612, 2018.
[6] Rosario Gennaro and Steven Goldfeder. Fast multiparty threshold ecdsa with fast trustless setup. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pages 1179–1194. ACM, 2018.
[7] Rosario Gennaro, Stanis law Jarecki, Hugo Krawczyk, and Tal Rabin. Robust and efficient sharing of RSA functions. In Advances in Cryptology – CRYPTO 1996, pages 157–172. Springer, 1996.
[8] Steven Goldfeder, Rosario Gennaro, Harry Kalodner, Joseph Bonneau, Joshua A Kroll, Edward W Felten, and Arvind Narayanan. Securing bitcoin wallets via a new DSA/ECDSA threshold signature scheme, 2015.
[9] Yehuda Lindell. Fast secure two-party ECDSA signing. In Advances in Cryptology – CRYPTO 2017, pages 613–644. Springer, 2017.
[10] Yehuda Lindell and Ariel Nof. Fast secure multiparty ecdsa with practical distributed key generation and applications to cryptocurrency custody. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pages 1837–1854. ACM, 2018.
[11] Philip MacKenzie and Michael K Reiter. Delegation of cryptographic servers for capture-resilient devices. Distributed Computing, 16(4):307–327, 2003.
[12] Philip MacKenzie and Michael K Reiter. Networked cryptographic devices resilient to capture. International Journal of Information Security, 2(1):1–20, 2003.
[13] Antonio Marcedone, Rafael Pass, and abhi shelat. Minimizing trust in hardware wallets with two factor signatures. Cryptology ePrint Archive, Report 2018/???, 2018.
[14] Microchip. Atecc608a datasheet, 2018.
[15] Antonio Nicolosi, Maxwell N Krohn, Yevgeniy Dodis, and David Mazieres. Proactive two-party signatures for user authentication. In NDSS, 2003.
[16] Marek Palatinus, Pavol Rusnak, Aaron Voisine, and Sean Bowe. Mnemonic code for generating deterministic keys (bip39).
[17] Tal Rabin. A simplified approach to threshold and proactive RSA. In Advances in Cryptology – CRYPTO 1998, pages 89–104. Springer, 1998.
[18] T.C. Sottek. Nsa reportedly intercepting laptops purchased online to install spy malware, December 2013. [Online; posted 29-December-2013;].
submitted by dj-gutz to myrXiv [link] [comments]

Meet 'Bitcoin Clashic,' a Weird and Totally Unexpected Cryptocurrency Rebellion

This is the best tl;dr I could make, original reduced by 71%. (I'm a bot)
Perhaps because a controversial network split in Bitcoin was cancelled by its organizers last week, the cryptocurrency space has been left thirsting for some drama.
Thankfully, an anonymous person or group has delivered with a completely unexpected rebellion they've dubbed "Bitcoin Clashic."
What fresh hell is this? The trouble all started when Bitcoin Cash, itself an earlier fork of the original Bitcoin blockchain, underwent a scheduled hard fork on Monday that implemented some updates in the code.
On Tuesday, Jihan Wu, co-founder of Bitcoin mining giant Bitmain, announced on Twitter that a new block of data had appeared on the legacy Bitcoin Cash chain.
The mysterious campaign kicked into overdrive: A flashy website for "Bitcoin Clashic," a new name for the legacy Bitcoin Cash chain, appeared, and so did a Twitter account.
While the Bitcoin Clashic website still says that compatible digital wallets "Will be updated soon," Marek Palatinus, CEO of Satoshi Labs tweeted that Trezor does in fact support Clashic out-of-the-box.
Summary Source | FAQ | Feedback | Top keywords: Bitcoin#1 Clashic#2 chain#3 new#4 mined#5
Post found in /Bitcoin, /BitcoinAll, /EthereumClassic and /technology.
NOTICE: This thread is for discussing the submission topic. Please do not discuss the concept of the autotldr bot here.
submitted by autotldr to autotldr [link] [comments]

[Informational] [CC0] Maslow's Hierarchy of Coins

Hierarchical Deterministic Wallets

Bitcoin Wallets generate and store the private keys that control a user's funds. These keys are simply random numbers, chosen by the wallet from a range of numbers so vast that it is essentially impossible for there to be a collision with another wallet doing the same thing. Deterministic wallets, also known as HD wallets help to simplify backing up and restoring wallets by using a random seed number to deterministically generate all of a wallet's private keys.

Private Key Backups

Whenever a Bitcoin user receives funds, they need a new private key. This means that the set of numbers that are important to store and back up is increasing indefinitely. In the original Bitcoin wallet, this required refreshing a back-up with a new one every time a user received funds.
Over time, Bitcoin grew more valuable and this burden of security grew more tiresome and costly. To address the issue Satoshi Nakamoto in October of 2010 released Bitcoin version 0.3.14 which contained a key pool feature. This feature automatically pre-generated a set of keys, to remain in abeyance for the user's next receipt of funds. This made backing up a much less frequent necessity, only being necessary after key pool exhaustion.
Over the following years, many other methods of improving key backups were tried. A popular concept of a paper wallet arose: printing a private key onto paper to store in a secure location. However this concept fell out of favor as being too complicated, vulnerable to printer information leaks, and encouraging address re-use.

Type 1 Deterministic Wallets

In August of 2011 Mike Caldwell sought to simplify and streamline the process of managing a collection of private keys. He created a Windows application called Bitcoin Address Utility that used a single random pass-phrase to deterministically create private keys from a single seed: essentially choosing one random number and then feeding it into a formula that would always produce more random numbers from the starting one.
This created a much easier way to backup private keys: simply secure the original random seed and restoring becomes a simple exercise of running the seed through the algorithm again.

Type 2 Deterministic Wallets

Mike Caldwell's Type 1 deterministic wallet design was based on a simple scheme that had a significant limitation: to receive funds with a Type 1 wallet required also having access to the private keys that could spend them. In situations such as merchant scripts or exchange wallets, this represented a security issue.
Before Mike Caldwell published his Type 1 wallet, in June of 2011 Greg Maxwell had already outlined a theoretical improvement to the Type 1 scheme, in which the public and private key generation might be separated to improve the security of stored funds. In Greg's outlined Type 2 scheme, a script could use what is called a master public key to generate new addresses, without ever being able to spend those funds.
In February of 2012, Pieter Wuille came up with a formalization and standardized version of this concept, in BIP 32. A surge of wallet development activity followed the deterministic wallet concept. Since the master seed behind the wallet may be represented as a simple series of twelve words, it was widely considered to be the superior method for Bitcoin wallet private key generation.
Alan Reiner was the first to implement a Type 2 seed in Armory Wallet, and helped give feedback to the BIP 32 formalization. Since then, every major wallet has moved to support the feature.

BIP 44 Deterministic Wallets

After BIP 32, development of Type 2 deterministic wallets progressed to a state where additional features and standardization was sought to be defined. In April of 2014 Marek Palatinus, also known as Slush, and Pavol Rusnak, Slush's employee at his company SatoshiLabs, sought to advance the state of deterministic wallets by adapting advancements in their own Type 2 hardware wallet Trezor into a standard they authored in BIP 44.
Features promoted by the BIP 44 standard included a mechanism for internal pass-phrase protected accounts inside of a wallet seed, a standard for using the wallet seed across multiple chains, such as for Bitcoin Testnet, and an increased standardization of gap limits and change address separation.

Deterministic Wallet Caveats

Despite the huge improvement in the state of Bitcoin technology that HD wallets represent, there are some outstanding issues and drawbacks or gotchas that may present difficulties.
Deterministic wallets generally present users with a dictionary derived random pass-phrase that actually represents a master seed number in a form that is easier for humans to deal with. But this ease-of-use has sometimes tempted developers into allowing users to set their own pass-phrase, a very bad idea. Users are extremely bad at choosing a properly random pass-phrase, and this behavior can lead to loss of funds. For this reason, all well-maintained wallets have ceased the practice of encouraging users to invent their own pass-phrases.
Another issue that sometimes confronts users in unexpected ways is that the seeds created by deterministic wallets should not be shared between wallets from different software projects. The reason for this is that the standard for deterministic wallets is generally not actually adopted by all wallets, or there are still areas left unspecified. Due to these small differences, seeds may superficially appear to be share-able between wallets, but in actuality leave some coins difficult to access from the non-originating wallet. To switch between deterministic wallets, the best practice recommendation is to initiate fund transfers on the Blockchain.
From a security and privacy perspective, under normal circumstances a deterministic wallet is just as good as a wallet in which random keys are individually generated. However use of the public master key can prove the exception to that rule. Although it is called a public master key, for privacy reasons it should not be shared publicly, as it can link all wallet addresses together. Another important reason it should not be shared is that if a single private key derived from the private seed is leaked and the public master key is also known, all the other private keys may be derived as well. This type of theft is quite uncommon, but for these reasons it is strongly recommended that the master public key still be treated as guarded information.
One practice that must differ between using an individually generated wallet and a deterministic wallet is the practice of creating addresses that are never used. HD wallets have a key implementation detail in the way that they calculate wallet balances: they go through their deterministic algorithm sequentially to determine if each private key has been used, stopping when no further activity is detected. This is a critical optimization, an HD wallet cannot scan endlessly or know automatically all of its balance information without individual queries. To provide a safety margin, HD wallets use something called a gap limit, which represents the number of keys checked that have no activity before the balance query will cease its sequential checking. This gap limit can means that creating many addresses that are never used is a bad practice and can lead to users mistakenly believing their funds have been lost, if more unused addresses are created beyond the gap limit safety margin.
A powerful feature of BIP 44 HD wallets is the internal pass phrase account system. This feature addresses a common security concern amongst people who worry about keeping their seed backups secure from theft: it adds an internal password to the stored seed. The feature also powers another use-case, a scenario in which the owner is confronted with the seed and forced to give access to it. As a precautionary measure, the owner may create a red-herring pass phrase and a real pass-phrase, pretending that the red-herring phrase contains the entirety of the funds when forced to open the wallet under duress. But with this power also comes risk deriving from any situation where users choose pass phrases to remember. Human generated pass phrases should generally be considered weak: a brute-force attack can most often bypass them. And memorized pass phrases can be easily forgotten, leading to an annoying situation where funds are temporarily inaccessible, or if a truly strong pass-phrase has been chosen, permanently lost.
submitted by pb1x to writingforbitcoin [link] [comments]

[Informational] [CC0] The Life and Times of BIPs

The Bitcoin Improvement Proposals or BIPS system is a design framework for submitting, reviewing and introducing changes to Bitcoin in a decentralized way. The framework was modeled off of BitTorrent's improvement system, and it was first proposed by Amir Taaki in August of 2011.
BIPs introduce changes in three ways:
  1. Informational BIPs describe guidelines or formalize design ideas
  2. Process BIPs describe changes in methodology around the development process.
  3. Standards Track BIPs describe network protocol changes, consensus rule changes, or any other impactful protocol changes.
BIPs follow a life-cycle where they are drafted, accepted, and finalized. Drafted BIPs that are not accepted can be withdrawn or redrafted. To update a finalized BIP, a replacement can be submitted to replace it.

Notable BIPs

BIP 0001 - BIP Purpose and Guidelines

Amir Taaki proposed the first BIP that defined the BIPs system in August of 2011. Originally modeled after the BitTorrent Enhancement Proposals and named Bitcoin Enhancement Proposals, the name was changed to Bitcoin Improvement Proposals to avoid an abbreviation conflict.

BIP 0011 - M-of-N Standard Transactions

Gavin Andresen was the first to create a standard type BIP, which outlined a proposal to add a multisig transaction type

BIP 0013 - Address Format for pay-to-script-hash

Gavin Andresen proposed a new address type for P2SH transactions, marked with a leading "3"

BIP 0014 - Protocol Version and User Agent

Amir Taaki and Patrick Strateman proposed a Bitcoin User-Agent standard.

BIP 0016 - Pay to Script Hash

Gavin Andresen proposed a method for creating addresses that supported script based redemption in order to empower multi-sig and other complex transaction types.

BIP 0021 - URI Scheme

Matt Corallo and Nils Schneider adapted Luke-Jr's earlier BIP to formalize a Bitcoin URI standard to make the process of making payments via links and QR more user friendly.

BIP 0022 - getblocktemplate

Luke-Jr formalized a system for sending block structures to hashers instead of just headers, in order to promote decentralization. The system was extended to cover pooled mining in BIP 0023

BIP 0032 - Hierarchical Deterministic Wallets

Pieter Wuille created a concept for wallets to build out a supply of private keys deterministically from a starting seed value, to make backing up and restoring a wallet a simpler process.

BIP 0034 - Block v2, Height in Coinbase

Gavin Andresen proposed a versioning process for blocks and a block version increase to v2.

BIP 0044 - Multi-Account Hierarchy for Deterministic Wallets

Marek Palatinus and Pavol Rusnak proposed an increased formalization of the deterministic wallet system for standardization reasons.

BIP 0050 - March 2013 Chain Fork Post-Mortem

Gavin Andresen wrote a description of a problem that led to a disastrous accidental Bitcoin hard fork that led to hundreds of Bitcoins being double spent.


Also known as OP_HODL, Peter Todd proposed a new operation code to indicate that a transaction's funds may not be spent until a specified future date.

BIP 0070 - Payment Protocol

Gavin Andresen and Mike Hearn proposed a protocol standard for coordinating the details of a Bitcoin payment, oriented towards the merchant and customer use-case.


BtcDrak, Mark Friedenbach, and Eric Lombrozo proposed an upgrade to the Bitcoin script to enable transaction scripts based on relative time values. Using this opcode, escrow transactions may include timeouts to avoid a scenario in which funds are stuck through a cooperation failure.

BIP 0141 - Segregated Witness

Johnson Lau, Eric Lombrozo, and Pieter Wuille proposed a large improvement to Bitcoin transactions that clearly split transactions so that all of the data related to the scripting and signing of the transaction was separated into its own demarcated section. Splitting this data out fixes various issues, chief among them a problem called transaction malleability in which duplicate versions of the same transaction could exist on the network.
submitted by pb1x to writingforbitcoin [link] [comments]

Marek Palatinus, Pavol Rusnák - Trezor, hardwarová peneženka pro Bitcoin Prečo vznikol bitcoin vysvetlí Marek Palatinus Vyplatí se těžba bitcoinů, a jakou roli v procesu hraje cena energie? Marek Palatinus, Trezor - The European Bitcoin Convention -- 2013 Amsterdam 10. Investiční večer: Bitcoin 4/9 - Je bitcoin investice?

Marek Palatinus, aka "Slush", is CEO & IT Architect at SatoshiLabs. He is an Bitcoin innovator and long-time evangelist. Palatinus is also the founder of world's first Bitcoin pool, Slush Pool, as well as and the first Bitcoin hardware wallet called TREZOR. Marek Palatinus as the New CEO. With Alena leaving the team, Marek Palatinus, the Architect of TREZOR, takes over as the new CEO of SatoshiLabs. Marek, alongside with Alena and Pavol “Stick” Rusnak, is the original founder of SatoshiLabs and one of the co-inventors of TREZOR. He also stands behind the first bitcoin mining pool in the world ... I'm Marek Palatinus (slush), creator of the first mining pool and creator of TREZOR. AMA - 3rd Dec! Forum rules The more people that are involved, the more interesting this AMA series will be for everyone. Please help spread the word of this amazing AMA series on your own social media. (YES, EVEN YOURS!) Short URL: Hashtag: #BTCAMA When the AMAs are finished, all the answers ... /r/btc was created to foster and support free and open Bitcoin discussion, Bitcoin news, and exclusive AMA (Ask Me Anything) interviews from top... Das behaupten die tschechischen Spezialisten der digitalen Community, die seit sechs Jahren mit Bitcoin arbeiten. hat sich in einem exklusiven Interview mit CEO und Gründer SatoshiLabs, Marek Palatinus, über die reale Problematik von Hackerangriffen unterhalten und geklärt, warum Sicherheit zuallererst bei einem selbst anfängt.

[index] [48655] [24401] [49145] [41579] [40187] [22330] [28019] [2878] [39402] [17973]

Marek Palatinus, Pavol Rusnák - Trezor, hardwarová peneženka pro Bitcoin

Jeho hosty byli Karel Minx, provozovatel webu, a Marek Palatinus, provozovatel webu Čtvrtá část večera: Je bitcoin investice? Category News & Politics; Show more Show ... Hosťom bol Marek Palatinus známi pod prezývkou Slush. Rozprávali sme sa o ha... Skip navigation Sign in. Search. Loading... Close. This video is unavailable. Watch Queue Queue . Watch Queue ... Marek Palatinus, Trezor - The European Bitcoin Convention -- 2013 Amsterdam Recorded By IamSatoshi Přednášející Marek Palatinus, který je propagátorem a gestorem tohoto projektu v českých zemích, představuje alternativní digitální měnu Bitcoin, která narozdíl od většiny měn ... Jak podniká bitcoinový průkopník Marek Palatinus a jak naopak vidí využití bitcoinu v podnikání? Poslouchat jako audio podcast: