Extract ECDSA parameters from Bitcoin Blockchain Block

[CCS Results] Monero Atomic Swaps research

Hi Monero community!
Two months ago I posted a CCS for continuing my research on Monero Atomic Swaps. That research is now complete and I'm happy to present my results.
This post will be a summary of my research, but you can also find the whitepaper that describes the full protocol and all the details here.

Shiny BTC/XMR Atomic Swap Protocol!

We found it! With the help of the MRL, my colleagues, and the community, we created the first (to our knowledge) protocol to atomically swap bitcoin and monero. And this resulting protocol is implementable today - no more obscure crypto!

Why now? What changed?

When I started studying Monero for a Bitcoin/Monero atomic swap three and a half years ago, most of the swap protocols where based on 'Hash Time Locked Contract' (HTLC), something that we all know as non-existent on Monero. So the goal at the beginning of the project was to create an atomic swap where all the logic (timeouts, possible sequences of operation, secret disclosures, etc) is managed on the other chain: the Bitcoin chain.
The second difficulty with Monero and Bitcoin is their respective underlying cryptographic parameters: they don't share the same elliptic curve, they don't share the same signing algorithm; they have nothing in common! This makes the pair a bad candidate for other types of atomic swap that don't (solely) rely on HTLC.
In November 2018 we came up with a draft protocol that respects the above constraints. Thus, the protocol requires a specific type of zero-knowledge proof to be trustless: a hash pre-image zero-knowledge proof. This type of zkp is not wildly used in practice, if at all. Thus the protocol works in theory, but with some obscure crypto, making the protocol a bad candidate for an implementation.
In early 2020, after presenting the draft protocol at 36C3 in December 2019, I discovered, by reference from Sarang Noether (MRL), Andrew Poelstra's idea of doing a discrete logarithm equality across group zero-knowledge proof of knowledge (MRL-0010), meaning that we can prove some relations between elements in two different groups (two curves to simplify) and the paper by LLoyd Fournier on One-Time Verifiably Encrypted Signatures allowing secret disclosure with ECDSA.
With these two new (to me) cryptographic primitives, we were able to replace the previous zero-knowledge proof with a combination of the latter, making the protocol complete and practically feasible.

How it works

As a broad overview (and simplified) the protocol work as follow:
If the swap succeeds, A reveals to B, and if the swap is cancelled, B reveals to A. (We have a third scenario explained in the paper to force reaction and avoid deadlock.)

Next steps

The obvious next step would be to have a working implementation on mainnet, but a ready-to-use implementation that is also robust and safe-to-use requires a lot of engineering work. Furthermore, even though the cryptography is not too obscure, most of it still also lacks an implementation.
I'll post soon, if the community wants it, a CCS proposal to get my team and I to work on implementing this protocol, step by step, with the end goal of creating a working client/daemon for swapping Bitcoin and Monero. It would be very exciting to build that!

Conclusion

Thanks to the MRL and its researchers for their help, the CCS team, and the community for its support!
I hope I fulfilled the community's expectations for my my first CCS - all feedback is appreciated.
submitted by h4sh3d to Monero [link] [comments]

08-13 21:45 - 'Building the Infrastructure for the Future Decentralized Financial Market, Coinbase Included HBTC.Com Debut DeFi Project - Nest Protocol' (self.Bitcoin) by /u/Nest_Fan removed from /r/Bitcoin within 24-34min

'''
As the world’s leading regulatory compliant digital asset exchange, Coinbase sets one of the most stringent requirements for digital asset listing which includes technical evaluation of projects, legal and risk analysis, market supply and demand analysis, and crypto-economics. Coinbase holds a strong reputation in the digital asset industry, and thus the “Coinbase Standard” is considered as the industry benchmark for other digital asset projects, and the market has even seen the “Coinbase effect”.
On July 25 2020, Coinbase quietly launched the pricing chart of a decentralized oracle project, NEST Protocol (NEST), into its portal. Although Coinbase has yet to announce the inclusion of the project in its evaluation list, it represents a keen interest in the DeFi sector, and particularly in the DeFi price oracle projects.
NEST Protocol is the rising star in the decentralized price oracle sector
Decentralized financial services offered by the current mainstream DeFi platforms such as MakerDAO, Compound, dYdX, etc. rely heavily on the market data provided by the oracle projects. Oracle projects act as reliable information sources to feed these price data to other DeFi Projects, connecting the price data from the centralized world to the DeFi space. As such, the price oracle is an integral part of the decentralized financial services infrastructure.
Traditionally, the price oracle collects data from different platforms and feeds these data points to the DeFi space to create data reference points to enable them to function properly. However, many problems currently exist in the DeFi space, for example, blockchain network congestion, malicious attacks, wild market fluctuations, and other factors that may cause the data given by the price oracle to deviate from the true market data. These ultimately cause users to trade on wrong information in the DeFi space and increases such transaction costs.
Decentralized finance requires a fast, secure, and reliable price oracle. The birth of the decentralized price oracle is the embodiment of the blockchain industry’s thinking, and the current market projects offering decentralized price oracle services which includes NEST Protocol, Chainlink, Band Protocol, Tellor, Witness, Oraclize, and many others.
The innovation of NEST-Price is that every data point has been agreed upon by market validators, in line with the blockchain consensus mechanism. NEST-Price synchronizes the off-chain price in a highly decentralized manner, creating real and valid price data on-chain. This is the unique differentiator between NEST-Price and other price oracles.
Compared with other price oracle projects, NEST also has other features and advantages, such as the proposed peer-to-peer quotation matching as well as its unique verifier verification structure, making NEST more resilient to malicious attacks, resulting in a more decentralized network, and it’s on-chain prices closer to the fair market price. All of this has resulted in the NEST Protocol becoming a rising star in the DeFi price oracle sector. HBTC.com selects high-quality projects to list and partnering with NEST to promote the development of DeFi ecosystem
During the selection of quality assets, exchanges like [HBTC.com]1 and Coinbase adhere to the principle of a rigorous selection of assets from different projects to enable a proper range of digital assets. At the same time, in order to solve existing pain points in the digital asset industry, which currently lacks a market-making management solution, HBTC.com also has launched its own “coin listing crowdsourcing [liquidity initiative]2 “, redefining the exchange market making model.
HBTC.com, through its coin listing strategy, effectively reduces the problem of low liquidity in the early stages of high-quality projects, ensuring the smoothness of the user experience, and achieves a win-win situation for traders, the community, and the respective trading platform. These initiatives, coupled with reliable user protection and a responsible attitude, have earned a positive reputation among users.
Since its inception, the HBTC.com exchange has been committed to the discovery of both quality and promising digital asset projects. At a time when DeFi is growing rapidly, HBTC.com has a unique perspective for the decentralized price oracle sector and has prioritized NEST as a premium partner to debut the project alongside with its global branding upgrade. In addition, HBTC.com has [100% proof of reserves]3 for traders to validate the existence of assets via the Merkle tree, which brings transparency to the extreme.
In May 2020, NEST token delivered a 883.29% of return, at its peak, after its global debut on HBTC.com. At present, HBTC Exchange addresses holding NEST token accounts in a total of 141 million, ranked first in the overall network. At the same time, the HBTC Exchange network exclusively releases NEST staking mining and data show that NEST 24-hour turnover has reached $20.4 million.
Post-listing of the NEST token, HBTC.com has also listed DeFi projects such as DF, OKS, NEST, SWTH, JST, NVT, and other DeFi projects with market potential; some projects have achieved astonishing performance in the secondary market.
HBTC.com’s path to DeFi: developing public chains to prepare for the future ecosystem breakout.
In terms of the DeFi product and ecosystem infrastructure, HBTC has deployed HBTC Chain since launched in 2018, an infrastructure designed for decentralized finance and DeFi business with patented Bluehelix decentralized cross-chain clearing and custody technology.
The HBTC Chain is the DeFi ecosystem infrastructure that the team has spent a significant amount of effort to build. It is based on decentralization and community consensus and integrates cryptography and blockchain technologies to support decentralized association-based governance capabilities at the technical level. Based on decentralized key management, combining various cryptography tools including ECDSA, commitment, zero-knowledge proof, and multi-party computation, It implements the distributed private key generation and signature for cross-chain assets among all validators. On top of that, this technology can realize light-weight and non-intrusive cross-chain asset custody. On the clearing layer, HBTC Chain employs BHPOS consensus and horizontal sharding mechanisms to achieve high-performing transaction clearing, and implementation of OpenDex protocol to help the development of the DeFi ecosystem.
In addition, with the success experience of Bluehelix Cloud SaaS and white label solutions and the HBTC Brokerage system, HBTC’s public chain also innovatively supports CEX+DEX mixed matchmaking model and OpenDex protocol and proposes the three-tier node system which consists of standard node + consensus node + core node. This structure provides HBTC public chain certain advantages in terms of performance and cross-chain transactions. Users can easily establish a DEX with OpenDex protocol at nearly zero cost, and all DEX will share the liquidity and support customized user interface and trading parameters. The trading experience can be completely comparable to centralized spot exchanges.
With the launch of its test network, it is now possible to develop various DeFi applications on the HBTC public chain, such as decentralized swap, so that private keys are not controlled by any party; no KYC, which can prevent personal information leakage; and asset security through the setting of invalidation, cancellation of transactions and other functions, cross-chain asset mappings, such as the ability to issue cross-chain cBTC or other chain tokens, fully decentralized asset mapping contracts, and 100% reserves.
Conclusion
In the past few months, the DeFi market has been extremely active, the price of DeFi tokens has been rising, and a new round of competition with the centralized exchanges has started. HBTC Chain relies on the powerful technology of Bluehelix and [HBTC.com]1 , giving all public chains the ability to interconnect, and put into both DeFi and SaaS levels. Undoubtedly, as one of the first exchanges to build the DeFi ecosystem, HBTC is leading the breakout in the current DeFi craze and has now become the first choice of users to engage with quality DeFi projects.

From BITCOIN news([[link]6 )
'''
Building the Infrastructure for the Future Decentralized Financial Market, Coinbase Included HBTC.Com Debut DeFi Project - Nest Protocol
Go1dfish undelete link
unreddit undelete link
Author: Nest_Fan
1: *btc*com/ 2: m*diu**com/hbt***ficia*/hbt*-launches-ba**liquidi*y***owd*unding-li*ti*g-plan-redefine-t*e*exch*nge-*i*tin**m*d*l***6*58f*f1d* 3: hbtc.ze**e*k*co*/hc/*n-us/a**icles/3***46287754-HBT*-10*-*ro***of*Reserve 4: hb*c.co*/ 5: n*ws.bitcoin.c*m*bu*ld*ng-t**-infr***ructur*-f*r-the*fut*re*decen**ali**d-*inanc*a*-market-coi**as*-*ncluded-h*t*-*o*-*ebut-de**-p*oject-n*st-**otocol* 6: n**s.bit*oin*com/building-th*-infrast*u*ture*for-t*e-fut****decen**a**zed**inancia*-m*rket-coinbase-**c*uded-*b*c-c***deb***defi-**oject-*est**r**ocol/]^^5
Unknown links are censored to prevent spreading illicit content.
submitted by removalbot to removalbot [link] [comments]

ECDSA In Bitcoin

Digital signatures are considered the foundation of online sovereignty. The advent of public-key cryptography in 1976 paved the way for the creation of a global communications tool – the Internet, and a completely new form of money – Bitcoin. Although the fundamental properties of public-key cryptography have not changed much since then, dozens of different open-source digital signature schemes are now available to cryptographers.

How ECDSA was incorporated into Bitcoin

When Satoshi Nakamoto, a mystical founder of the first crypto, started working on Bitcoin, one of the key points was to select the signature schemes for an open and public financial system. The requirements were clear. An algorithm should have been widely used, understandable, safe enough, easy, and, what is more important, open-sourced.
Of all the options available at that time, he chose the one that met these criteria: Elliptic Curve Digital Signature Algorithm, or ECDSA.
At that time, native support for ECDSA was provided in OpenSSL, an open set of encryption tools developed by experienced cipher banks in order to increase the confidentiality of online communications. Compared to other popular schemes, ECDSA had such advantages as:
These are extremely useful features for digital money. At the same time, it provides a proportional level of security: for example, a 256-bit ECDSA key has the same level of security as a 3072-bit RSA key (Rivest, Shamir и Adleman) with a significantly smaller key size.

Basic principles of ECDSA

ECDSA is a process that uses elliptic curves and finite fields to “sign” data in such a way that third parties can easily verify the authenticity of the signature, but the signer himself reserves the exclusive opportunity to create signatures. In the case of Bitcoin, the “data” that is signed is a transaction that transfers ownership of bitcoins.
ECDSA has two separate procedures for signing and verifying. Each procedure is an algorithm consisting of several arithmetic operations. The signature algorithm uses the private key, and the verification algorithm uses only the public key.
To use ECDSA, such protocol as Bitcoin must fix a set of parameters for the elliptic curve and its finite field, so that all users of the protocol know and apply these parameters. Otherwise, everyone will solve their own equations, which will not converge with each other, and they will never agree on anything.
For all these parameters, Bitcoin uses very, very large (well, awesomely incredibly huge) numbers. It is important. In fact, all practical applications of ECDSA use huge numbers. After all, the security of this algorithm relies on the fact that these values are too large to pick up a key with a simple brute force. The 384-bit ECDSA key is considered safe enough for the NSA's most secretive government service (USA).

Replacement of ECDSA

Thanks to the hard work done by Peter Wuille (a famous cryptography specialist) and his colleagues on an improved elliptical curve called secp256k1, Bitcoin's ECDSA has become even faster and more efficient. However, ECDSA still has some shortcomings, which can serve as a sufficient basis for its complete replacement. After several years of research and experimentation, a new signature scheme was established to increase the confidentiality and efficiency of Bitcoin transactions: Schnorr's digital signature scheme.
Schnorr's signature takes the process of using “keys” to a new level. It takes only 64 bytes when it gets into the block, which reduces the space occupied by transactions by 4%. Since transactions with the Schnorr signature are the same size, this makes it possible to pre-calculate the total size of the part of the block that contains such signatures. A preliminary calculation of the block size is the key to its safe increase in the future.
Keep up with the news of the crypto world at CoinJoy.io Follow us on Twitter and Medium. Subscribe to our YouTube channel. Join our Telegram channel. For any inquiries mail us at [[email protected]](mailto:[email protected]).
submitted by CoinjoyAssistant to btc [link] [comments]

ECDSA In Bitcoin

Digital signatures are considered the foundation of online sovereignty. The advent of public-key cryptography in 1976 paved the way for the creation of a global communications tool – the Internet, and a completely new form of money – Bitcoin. Although the fundamental properties of public-key cryptography have not changed much since then, dozens of different open-source digital signature schemes are now available to cryptographers.

How ECDSA was incorporated into Bitcoin

When Satoshi Nakamoto, a mystical founder of the first crypto, started working on Bitcoin, one of the key points was to select the signature schemes for an open and public financial system. The requirements were clear. An algorithm should have been widely used, understandable, safe enough, easy, and, what is more important, open-sourced.
Of all the options available at that time, he chose the one that met these criteria: Elliptic Curve Digital Signature Algorithm, or ECDSA.
At that time, native support for ECDSA was provided in OpenSSL, an open set of encryption tools developed by experienced cipher banks in order to increase the confidentiality of online communications. Compared to other popular schemes, ECDSA had such advantages as:
These are extremely useful features for digital money. At the same time, it provides a proportional level of security: for example, a 256-bit ECDSA key has the same level of security as a 3072-bit RSA key (Rivest, Shamir и Adleman) with a significantly smaller key size.

Basic principles of ECDSA

ECDSA is a process that uses elliptic curves and finite fields to “sign” data in such a way that third parties can easily verify the authenticity of the signature, but the signer himself reserves the exclusive opportunity to create signatures. In the case of Bitcoin, the “data” that is signed is a transaction that transfers ownership of bitcoins.
ECDSA has two separate procedures for signing and verifying. Each procedure is an algorithm consisting of several arithmetic operations. The signature algorithm uses the private key, and the verification algorithm uses only the public key.
To use ECDSA, such protocol as Bitcoin must fix a set of parameters for the elliptic curve and its finite field, so that all users of the protocol know and apply these parameters. Otherwise, everyone will solve their own equations, which will not converge with each other, and they will never agree on anything.
For all these parameters, Bitcoin uses very, very large (well, awesomely incredibly huge) numbers. It is important. In fact, all practical applications of ECDSA use huge numbers. After all, the security of this algorithm relies on the fact that these values are too large to pick up a key with a simple brute force. The 384-bit ECDSA key is considered safe enough for the NSA's most secretive government service (USA).

Replacement of ECDSA

Thanks to the hard work done by Peter Wuille (a famous cryptography specialist) and his colleagues on an improved elliptical curve called secp256k1, Bitcoin's ECDSA has become even faster and more efficient. However, ECDSA still has some shortcomings, which can serve as a sufficient basis for its complete replacement. After several years of research and experimentation, a new signature scheme was established to increase the confidentiality and efficiency of Bitcoin transactions: Schnorr's digital signature scheme.
Schnorr's signature takes the process of using “keys” to a new level. It takes only 64 bytes when it gets into the block, which reduces the space occupied by transactions by 4%. Since transactions with the Schnorr signature are the same size, this makes it possible to pre-calculate the total size of the part of the block that contains such signatures. A preliminary calculation of the block size is the key to its safe increase in the future.
Keep up with the news of the crypto world at CoinJoy.io Follow us on Twitter and Medium. Subscribe to our YouTube channel. Join our Telegram channel. For any inquiries mail us at [[email protected]](mailto:[email protected]).
submitted by CoinjoyAssistant to Bitcoin [link] [comments]

Best General RenVM Questions of March 2020

Best General RenVM Questions of March 2020

\These questions are sourced directly from Telegram*

Q: How do I shutdown my Chaosnet Darknode? A: Please follow these directions: https://docs.renproject.io/chaosnet/chaosnet-darknode/untitled-3

Q: Can I run a Chaosnet Darknode and Mainnet Darknode at the same time (on the same computer). A: No, if you want to do that you’ll have to run them on separate computers.

Q: You mentioned DCEP in your latest piece and "12 App Ideas", but it's going to run on a centralized private network. The Bank of England also just released a report on how they're thinking about their CBDC and DLT/centralization, and stress that a DLT could add resilience, but there's also no reason a currency couldn't be more centralized. The Block reported that other central banks (like the EU and Singapore) are considering third-party chains like Corda. Can you comment on which CBDC designs may or may not be compatible with RZL? You previously said "RZL sMPC provides ECDSA signatures because that’s what it is used by Ethereum, Bitcoin, etc. Whatever solution they come up with, will be the solution that RZL has to be upgraded to use (the whole point of RenVM is not to tell other chains how to do things, and still provide interop; this means waiting on them to define their solution and then working with that)." So, what does centralization mean for RZL, and how can we think about compatibility between these designs on the technical side?
A: The topic of centralisation in interoperability comes down to the compounding effect of using multiple networks. Put another way “you’re only as decentralised as your most centralised component”. While there are nuances to this, the core idea rings true.
RenVM can be used to interoperate many different kinds of chains (anything using ECDSA, or naturally supporting lively threshold signatures) is a candidate to be included in RenVM. However, a centralised currency that has been bridged to a decentralised chain is not decentralised. The centralised entity that controls the currency might say “nothing transferred to/from this other chain will be honoured”. That’s a risk that you take with centralised currencies (take a look at the T&Cs for USDC for example).
The benefit of RenVM in these instances is to become a standard. Short-term, RenVM brings interoperability to some core chains. Medium-term, it expands that to other more interesting chains based on community demands. Long-term, it becomes the standard for how to implement interop. For example: you create a new chain and don’t worry about interop explicitly because you know RenVM will have your back. For centralised currencies this is still advantageous, because the issuing entity only has to manage one chain (theirs) but can still get their currency onto other chains/ecosystems.
From a technical perspective, the Darknodes just have to be willing to adopt the chain/currency.

Q: dApps will have their own risk tolerances for centralized assets. Eg USDC was a bigger deal for MakerDAO than Uniswap. If CBDC liquidity were suddenly bridgeable, some dApps would be more eager to adopt it than others - even despite the risks - because they provide native liquidity and can be used to store/hedge in it without cashing it out. My question is more technical as it relates to RenVM as the "Universal Stablecoin Converter". You sound convinced that RenVM can bridge Libra, DCEP, maybe other CBDCs in the future, but I'm skeptical how RenVM works with account-based currencies. (1) Are we even sure of DCEP's underlying design and whether it or other CBDCs even plan to use digital signatures? And (2) wouldn't RenVM need a KYC-approved account to even get an address on these chains? It seems like DCEP would have to go through a Chinese Circle, who would just issue an ERC20.
A: As far as underlying blockchain technology goes (eg the maths of it) I don’t see there being any issues. Until we know more about whether or not KYCd addresses are required (and if they are, how they work), then I can’t specifically comment on that. However, it is more than possible not to require RenVM to be KYCd (just like you can’t “KYC Ethereum”) and instead move that requirement to addresses on the host blockchain (eg KYC Ethereum addresses for receiving the cross-chain asset). Whether this happens or not would ultimately be up to whether the issuer wanted interoperability to be possible.

Q: In that scenario, how would RenVM even receive the funds to be transferred to the KYC'd Ethereum address? For Alice to send DCEP to Bob's KYC'd Ethereum address, RenVM would need a DCEP address of its own, no?
A: Again, this is impossible to say for certain without knowing the implementation of the origin chain. You could whitelist known RenVM scripts (by looking at their form, like RenVM itself does on Bitcoin). But mostly likely, these systems will have some level of smart contract capabilities and this allows very flexible control. You can just whitelist the smart contract address that RenVM watches for cross-chain events. In origin chains with smart contracts, the smart contract holds the funds (and the keys the smart contract uses to authorise spends are handled as business logic). So there isn’t really a “RenVM public address” in the same sense that there is in Bitcoin.
Q: The disbonding period for Darknodes seem long, what happens if there is a bug?
A: It’s actually good for the network to have a long disbonding period in the face of a bug. If people were able to panic sell, then not only would the bug cause potential security issues, but so too would a mass exodus of Darknodes from the network.
Having time to fix the bug means that Darknodes may as well stick around and continue securing the network as best they can. Because their REN is at stake (as you put it) they’re incentivised to take any of the recommended actions and update their nodes as necessary.
This is also why it’s critical for the Greycore to exist in the early days of the network and why we are rolling out SubZero the way that we are. If such a bug becomes apparent (more likely in the early days than the later days), then the Greycore has a chance to react to it (the specifics of which would of course depend on the specifics of the bug). This becomes harder and slower as the network becomes more decentralised over time.
Not mcap, but the price of bonded Ren. Furthermore, the price will be determined by how much fees darknodes have collected. BTW, loongy could you unveil based on what profits ratio/apr the price will be calculated?
This is up to the Darknodes to governance softly. This means there isn’t a need for an explicit oracle. Darknodes assess L vs R individually and vote to increase fees to drive L down and drive R up. L is driven down by continue fees, whereas R is driven up by minting/burning fees.

Q: How do you think renvm would perform on a day like today when even cexs are stretched. Would the system be able to keep up?
A: This will really depend on the number of shards that RenVM is operating. Shards operate in parallel so more shards = more processing power.

Q: The main limiting factor is the speed of the underlying chain, rather than RenVM?
A: That’s generally the case. Bitcoin peaks at about 7 TPS so as long as we are faster than this, any extra TPS is “wasted”. And you actually don’t want to be faster than you have to be. This lets you drop hardware requirements, and lowering the cost of running a Darknode. This has two nice effects: (a) being an operator generates more profit because costs are lower, and (b) it’s more accessible to more people because it’s a little cheaper to get started (albeit this is minor).

Q: Just getting caught up on governance, but what about: unbonded REN = 1 vote, bonded REN = (1 vote + time_served). That'd be > decentralization of Darknodes alone, an added incentive to be registered, and counter exchanges wielding too much control.
A: You could also have different decaying rates. For example, assuming that REN holders have to vote by “backing” the vote of Darknodes:
Let X be the amount of REN used to voted, backed behind a Darknode and bonded for T time.
Let Y be the amount of time a Darknode has been active for.
Voting power of the Darknode could = Sqrt(Y) * Log(X + T)
Log(1,000,000,000) = ~21 so if you had every REN bonded behind you, your voting power would only be 21x the voting power of other nodes. This would force whales to either run Darknodes for a while and contribute actively to the ecosystem (or lock up their REN for an extended period for addition voting power), and would force exchanges to spread their voting out over many different nodes (giving power back to those running nodes). Obviously the exchange could just run lots of Darknodes, but they would have to do this over a long period of time (not feasible, because people need to be able to withdraw their REN).

Q: Like having superdelegates, i.e, nodes trusted by the community with higher voting power? Maybe like council nodes
A: Well, this is essentially what the Greycore is. Darknodes that have been voted in by the community to act as a secondary signature on everything. (And, interestingly enough, you could vote out all members to remove the core entirely.)

Q: Think the expensive ren is a security feature as well. So, doubt this would impact security potentially? I don’t know. I wouldn’t vote to cut my earnings by 40% for example lol
A: It can lead to centralisation over time though. If 100K REN becomes prohibitively expensive, then you will only see people running Darknodes that can afford a large upfront capital investment. In the mid/long-term this can have adverse effects on the trust in the system. It’s important that people “external” to the system (non-Darknodes) can get themselves into the system. Allowing non-Darknodes to have some governance (even if it’s not overall things) would be critical to this.

Q: That darknode option sounds very interesting although it could get more centralized as the price of 100k Ren rises.For instance dark nodes may not want to vote to lower the threshold from 100k to 50k once Ren gets too expensive.
A: A great point. And one of the reasons it would be ideal to be able to alter those parameters without just the Darknodes voting. Otherwise, you definitely risk long-term centralisation.

Q: BTC is deposited into a native BTC address, but who controls this address (where/how is this address’s private key stored)?
A: This is precisely the magic behind RenVM. RenVM uses an MPC algorithm to generate the controlling private key. No one ever sees this private key, and no one can sign things with it without consensus from everyone else.
submitted by RENProtocol to RenProject [link] [comments]

Best General RenVM Questions of January 2020

Best General RenVM Questions of January 2020

‌*These questions are sourced directly from Telegram
Q: When you say RenVM is Trustless, Permissionless, and Decentralized, what does that actually mean?
A: Trustless = RenVM is a virtual machine (a network of nodes, that do computations), this means if you ask RenVM to trade an asset via smart contract logic, it will. No trusted intermediary that holds assets or that you need to rely on. Because RenVM is a decentralized network and computes verified information in a secure environment, no single party can prevent users from sending funds in, withdrawing deposited funds, or computing information needed for updating outside ledgers. RenVM is an agnostic and autonomous virtual broker that holds your digital assets as they move between blockchains.
Permissionless = RenVM is an open protocol; meaning anyone can use RenVM and any project can build with RenVM. You don't need anyone's permission, just plug RenVM into your dApp and you have interoperability.
Decentralized = The nodes that power RenVM ( Darknodes) are scattered throughout the world. RenVM has a peak capacity of up to 10,000 Darknodes (due to REN’s token economics). Realistically, there will probably be 100 - 500 Darknodes run in the initial Mainnet phases, ample decentralized nonetheless.

Q: Okay, so how can you prove this?
A: The publication of our audit results will help prove the trustlessness piece; permissionless and decentralized can be proven today.
Permissionless = https://github.com/renproject/ren-js
Decentralized = https://chaosnet.renproject.io/

Q: How does Ren sMPC work? Sharmir's secret sharing? TSS?
A: There is some confusion here that keeps arising so I will do my best to clarify.TL;DR: *SSS is just data. It’s what you do with the data that matters. RenVM uses sMPC on SSS to create TSS for ECDSA keys.*SSS and TSS aren’t fundamental different things. It’s kind of like asking: do you use numbers, or equations? Equations often (but not always) use numbers or at some point involve numbers.
SSS by itself is just a way of representing secret data (like numbers). sMPC is how to generate and work with that data (like equations). One of the things you can do with that work is produce a form of TSS (this is what RenVM does).
However, TSS is slightly different because it can also be done *without* SSS and sMPC. For example, BLS signatures don’t use SSS or sMPC but they are still a form of TSS.
So, we say that RenVM uses SSS+sMPC because this is more specific than just saying TSS (and you can also do more with SSS+sMPC than just TSS). Specifically, all viable forms of turning ECDSA (a scheme that isn’t naturally threshold based) into a TSS needs SSS+sMPC.
People often get confused about RenVM and claim “SSS can’t be used to sign transactions without making the private key whole again”. That’s a strange statement and shows a fundamental misunderstanding about what SSS is.
To come back to our analogy, it’s like saying “numbers can’t be used to write a book”. That’s kind of true in a direct sense, but there are plenty of ways to encode a book as numbers and then it’s up to how you interpret (how you *use*) those numbers. This is exactly how this text I’m writing is appearing on your screen right now.
SSS is just secret data. It doesn’t make sense to say that SSS *functions*. RenVM is what does the functioning. RenVM *uses* the SSSs to represent private keys. But these are generated and used and destroyed as part of sMPC. The keys are never whole at any point.

Q: Thanks for the explanation. Based on my understanding of SSS, a trusted dealer does need to briefly put the key together. Is this not the case?
A: Remember, SSS is just the representation of a secret. How you get from the secret to its representation is something else. There are many ways to do it. The simplest way is to have a “dealer” that knows the secret and gives out the shares. But, there are other ways. For example: we all act as dealers, and all give each other shares of our individual secret. If there are N of us, we now each have N shares (one from every person). Then we all individually add up the shares that we have. We now each have a share of a “global” secret that no one actually knows. We know this global secret is the sum of everyone’s individual secrets, but unless you know every individual’s secret you cannot know the global secret (even though you have all just collectively generates shares for it). This is an example of an sMPC generation of a random number with collusion resistance against all-but-one adversaries.

Q: If you borrow Ren, you can profit from the opposite Ren gain. That means you could profit from breaking the network and from falling Ren price (because breaking the network, would cause Ren price to drop) (lower amount to be repaid, when the bond gets slashed)
A: Yes, this is why it’s important there has a large number of Darknodes before moving to full decentralisation (large borrowing becomes harder). We’re exploring a few other options too, that should help prevent these kinds of issues.

Q: What are RenVM’s Security and Liveliness parameters?
A: These are discussed in detail in our Wiki, please check it out here: https://github.com/renproject/ren/wiki/Safety-and-Liveliness#analysis

Q: What are the next blockchain under consideration for RenVM?
A: These can be found here: https://github.com/renproject/ren/wiki/Supported-Blockchains

Q: I've just read that Aztec is going to be live this month and currently tests txs with third parties. Are you going to participate in early access or you just more focused on bringing Ren to Subzero stage?
A: At this stage, our entire focus is on Mainnet SubZero. But, we will definitely be following up on integrating with AZTEC once everything is out and stable.

Q: So how does RenVM compare to tBTC, Thorchain, WBTC, etc..?
A: An easy way to think about it is..RenVM’s functionality is a combination of tBTC (+ WBTC by extension), and Thorchain’s (proposed) capabilities... All wrapped into one. Just depends on what the end-user application wants to do with it.

Q1: What are the core technical/security differences between RenVM and tBTC?A1: The algorithm used by tBTC faults if even one node goes offline at the wrong moment (and the whole “keep” of nodes can be penalised for this). RenVM can survive 1/3rd going offline at any point at any time. Advantage for tBTC is that collusion is harder, disadvantage is obviously availability and permissionlessness is lower.
tBTC an only mint/burn lots of 1 BTC and requires an on-Ethereum SPV relay for Bitcoin headers (and for any other chain it adds). No real advantage trade-off IMO.
tBTC has a liquidation mechanism that means nodes can have their bond liquidated because of ETH/BTC price ratio. Advantage means users can get 1 BTC worth of ETH. Disadvantage is it means tBTC is kind of a synthetic: needs a price feed, needs liquid markets for liquidation, users must accept exposure to ETH even if they only hold tBTC, nodes must stay collateralized or lose lots of ETH. RenVM doesn’t have this, and instead uses fees to prevent becoming under-collateralized. This requires a mature market, and assumed Darknodes will value their REN bonds fairly (based on revenue, not necessarily what they can sell it for at current —potentially manipulated—market value). That can be an advantage or disadvantage depending on how you feel.
tBTC focuses more on the idea of a tokenized version of BTC that feels like an ERC20 to the user (and is). RenVM focuses more on letting the user interact with DeFi and use real BTC and real Bitcoin transactions to do so (still an ERC20 under the hood, but the UX is more fluid and integrated). Advantage of tBTC is that it’s probably easier to understand and that might mean better overall experience, disadvantage really comes back to that 1 BTC limit and the need for a more clunky minting/burning experience that might mean worse overall experience. Too early to tell, different projects taking different bets.
tBTC supports BTC (I think they have ZEC these days too). RenVM supports BTC, BCH, and ZEC (docs discuss Matic, XRP, and LTC).
Q2: This are my assumed differences between tBTC and RenVM, are they correct? Some key comparisons:
-Both are vulnerable to oracle attacks
-REN federation failure results in loss or theft of all funds
-tBTC failures tend to result in frothy markets, but holders of tBTC are made whole
-REN quorum rotation is new crypto, and relies on honest deletion of old key shares
-tBTC rotates micro-quorums regularly without relying on honest deletion
-tBTC relies on an SPV relay
-REN relies on federation honesty to fill the relay's purpose
-Both are brittle to deep reorgs, so expanding to weaker chains like ZEC is not clearly a good idea
-REN may see total system failure as the result of a deep reorg, as it changes federation incentives significantly
-tBTC may accidentally punish some honest micro-federations as the result of a deep reorg
-REN generally has much more interaction between incentive models, as everything is mixed into the same pot.
-tBTC is a large collection of small incentive models, while REN is a single complex incentive model
A2: To correct some points:
The oracle situation is different with RenVM, because the fee model is what determines the value of REN with respect to the cross-chain asset. This is the asset is what is used to pay the fee, so no external pricing is needed for it (because you only care about the ratio between REN and the cross-chain asset).
RenVM does rotate quorums regularly, in fact more regularly than in tBTC (although there are micro-quorums, each deposit doesn’t get rotated as far as I know and sticks around for up to 6 months). This rotation involves rotations of the keys too, so it does not rely on honest deletion of key shares.
Federated views of blockchains are easier to expand to support deep re-orgs (just get the nodes to wait for more blocks for that chain). SPV requires longer proofs which begins to scale more poorly.
Not sure what you mean by “one big pot”, but there are multiple quorums so the failure of one is isolated from the failures of others. For example, if there are 10 shards supporting BTC and one of them fails, then this is equivalent to a sudden 10% fee being applied. Harsh, yes, but not total failure of the whole system (and doesn’t affect other assets).
Would be interesting what RenVM would look like with lots more shards that are smaller. Failure becomes much more isolated and affects the overall network less.
Further, the amount of tBTC you can mint is dependent on people who are long ETH and prefer locking it up in Keep for earning a smallish fee instead of putting it in Compound or leveraging with dydx. tBTC is competing for liquidity while RenVM isn't.

Q: I understand correctly RenVM (sMPC) can get up to a 50% security threshold, can you tell me more?
A: The best you can theoretically do with sMPC is 50-67% of the total value of REN used to bond Darknodes (RenVM will eventually work up to 50% and won’t go for 67% because we care about liveliness just as much as safety). As an example, if there’s $1M of REN currently locked up in bonded Darknodes you could have up to $500K of tokens shifted through RenVM at any one specific moment. You could do more than that in daily volume, but at any one moment this is the limit.Beyond this limit, you can still remain secure but you cannot assume that players are going to be acting to maximize their profit. Under this limit, a colluding group of adversaries has no incentive to subvert safety/liveliness properties because the cost to attack roughly outweighs the gain. Beyond this limit, you need to assume that players are behaving out of commitment to the network (not necessarily a bad assumption, but definitely weaker than the maximizing profits assumption).

Q: Why is using ETH as collateral for RenVM a bad idea?
A: Using ETH as collateral in this kind of system (like having to deposit say 20 ETH for a bond) would not make any sense because the collateral value would then fluctuate independently of what kind of value RenVM is providing. The REN token on the other hand directly correlates with the usage of RenVM which makes bonding with REN much more appropriate. DAI as a bond would not work as well because then you can't limit attackers with enough funds to launch as many darknodes as they want until they can attack the network. REN is limited in supply and therefore makes it harder to get enough of it without the price shooting up (making it much more expensive to attack as they would lose their bonds as well).
A major advantage of Ren's specific usage of sMPC is that security can be regulated economically. All value (that's being interopped at least) passing through RenVM has explicit value. The network can self-regulate to ensure an attack is never worth it.

Q: Given the fee model proposal/ceiling, might be a liquidity issue with renBTC. More demand than possible supply?A: I don’t think so. As renBTC is minted, the fees being earned by Darknodes go up, and therefore the value of REN goes up. Imagine that the demand is so great that the amount of renBTC is pushing close to 100% of the limit. This is a very loud and clear message to the Darknodes that they’re going to be earning good fees and that demand is high. Almost by definition, this means REN is worth more.
Profits of the Darknodes, and therefore security of the network, is based solely on the use of the network (this is what you want because your network does not make or break on things outside the systems control). In a system like tBTC there are liquidity issues because you need to convince ETH holders to bond ETH and this is an external problem. Maybe ETH is pumping irrespective of tBTC use and people begin leaving tBTC to sell their ETH. Or, that ETH is dumping, and so tBTC nodes are either liquidated or all their profits are eaten by the fact that they have to be long on ETH (and tBTC holders cannot get their BTC back in this case). Feels real bad man.

Q: I’m still wondering which asset people will choose: tbtc or renBTC? I’m assuming the fact that all tbtc is backed by eth + btc might make some people more comfortable with it.
A: Maybe :) personally I’d rather know that my renBTC can always be turned back into BTC, and that my transactions will always go through. I also think there are many BTC holders that would rather not have to “believe in ETH” as an externality just to maximize use of their BTC.

Q: How does the liquidation mechanism work? Can any party, including non-nodes act as liquidators? There needs to be a price feed for liquidation and to determine the minting fee - where does this price feed come from?
A: RenVM does not have a liquidation mechanism.
Q: I don’t understand how the price feeds for minting fees make sense. You are saying that the inputs for the fee curve depend on the amount of fees derived by the system. This is circular in a sense?
A: By evaluating the REN based on the income you can get from bonding it and working. The only thing that drives REN value is the fact that REN can be bonded to allow work to be done to earn revenue. So any price feed (however you define it) is eventually rooted in the fees earned.

Q: Who’s doing RenVM’s Security Audit?
A: ChainSecurity | https://chainsecurity.com/

Q: Can you explain RenVM’s proposed fee model?
A: The proposed fee model can be found here: https://github.com/renproject/ren/wiki/Safety-and-Liveliness#fees

Q: Can you explain in more detail the difference between "execution" and "powering P2P Network". I think that these functions are somehow overlapping? Can you define in more detail what is "execution" and "powering P2P Network"? You also said that at later stages semi-core might still exist "as a secondary signature on everything (this can mathematically only increase security, because the fully decentralised signature is still needed)". What power will this secondary signature have?
A: By execution we specifically mean signing things with the secret ECDSA keys. The P2P network is how every node communicates with every other node. The semi-core doesn’t have any “special powers”. If it stays, it would literally just be a second signature required (as opposed to the one signature required right now).
This cannot affect safety, because the first signature is still required. Any attack you wanted to do would still have to succeed against the “normal” part of the network. This can affect liveliness, because the semi-core could decide not to sign. However, the semi-core follows the same rules as normal shards. The signature is tolerant to 1/3rd for both safety/liveliness. So, 1/3rd+ would have to decide to not sign.
Members of the semi-core would be there under governance from the rest of our ecosystem. The idea is that members would be chosen for their external value. We’ve discussed in-depth the idea of L<3. But, if RenVM is used in MakerDAO, Compound, dYdX, Kyber, etc. it would be desirable to capture the value of these ecosystems too, not just the value of REN bonded. The semi-core as a second signature is a way to do this.
Imagine if the members for those projects, because those projects want to help secure renBTC, because it’s used in their ecosystems. There is a very strong incentive for them to behave honestly. To attack RenVM you first have to attack the Darknodes “as per usual” (the current design), and then somehow convince 1/3rd of these projects to act dishonestly and collapse their own ecosystems and their own reputations. This is a very difficult thing to do.
Worth reminding: the draft for this proposal isn’t finished. It would be great for everyone to give us their thoughts on GitHub when it is proposed, so we can keep a persistent record.

Q: Which method or equation is used to calculate REN value based on fees? I'm interested in how REN value is calculated as well, to maintain the L < 3 ratio?
A: We haven’t finalized this yet. But, at this stage, the plan is to have a smart contract that is controlled by the Darknodes. We want to wait to see how SubZero and Zero go before committing to a specific formulation, as this will give us a chance to bootstrap the network and field inputs from the Darknodes owners after the earnings they can make have become more apparent.
submitted by RENProtocol to RenProject [link] [comments]

Question about ECDSA private key recovery from known k parameter

I'm trying to solve a challenge about finding ECDSA private key from known k, and I encountered a problem that I can't google, so I hope someone will help me here.

I have a signature, a Bitcoin address, a message and the k parameter used to create the signature. I wrote a solution that works with my own test cases, but it fails with the challenge in the following way: the public key that gets derived from found private key is not the same as as the public key that corresponds to the Bitcoin address. However, signing the same message with the same k produces the same signature as the challenge signature (aside from special byte appended by Bitcoin). I suspected that the problem might be with the R, but R, and tried a few different values, even though it's already supplied by Bitcoin signature format, but still failed to produce the same public key.
Update: found the R value that leads to the same public key that I can derive from my found private key. Seems like this was a part of the challenge. Still, want to know the answer to my last question, as I don't know much theory about Ecdsa.
Update 2: after getting a hint, I found the private key by using -s instead of s to calculate the private key. But I don't fully understand how it worked, I see it has something to do with ECDSA malleability, so my second question is - how it all worked?
So, my question is - what I could be doing wrong? Can different private keys produce the same signature when k and message are the same?
submitted by Satoshi_Hodler to crypto [link] [comments]

The Math Behind Bitcoin

The Math Behind Bitcoin submitted by chaxhine to Bitcoin [link] [comments]

Keychain Accelerates Enterprise Blockchain Adoption with Bitcoin Data Security and Identity Layer

FYI
http://www.keychain.io/2019/09/04/1685/
Uses the Bitcoin blockchain as a public key infrastructure to secure off-chain data.
Capabilities:
Features:
Targeted sectors:
submitted by recursivesalt to u/recursivesalt [link] [comments]

gRPC LND Python Problem

I am currently struggling to work myself through gRPC with my LND Node using Python.
I've set everything up using this tutorial.
Getinfo works as described in the tutorial.
Now I created an invoice with Starblocks but struggle to get my head around how to satisfy it using a script.
My script:
import rpc_pb2 as ln import rpc_pb2_grpc as lnrpc import grpc import os # Due to updated ECDSA generated tls.cert we need to let gprc know that # we need to use that cipher suite otherwise there will be a handhsake # error when we communicate with the lnd rpc server. os.environ["GRPC_SSL_CIPHER_SUITES"] = 'HIGH+ECDSA' # Lnd cert is at ~/.lnd/tls.cert on Linux and # ~/Library/Application Support/Lnd/tls.cert on Mac cert = open(os.path.expanduser('/home/pi/.lnd/tls.cert'), 'rb').read() creds = grpc.ssl_channel_credentials(cert) channel = grpc.secure_channel('localhost:10009', creds) stub = lnrpc.LightningStub(channel) import codecs # Lnd admin macaroon is at ~/.lnd/data/chain/bitcoin/simnet/admin.macaroon on Linux and # ~/Library/Application Support/Lnd/data/chain/bitcoin/simnet/admin.macaroon on Mac with open(os.path.expanduser('/home/bitcoin/.lnd/data/chain/bitcoin/testnet/invoice.macaroon'), 'rb') as f: macaroon_bytes = f.read() macaroon = codecs.encode(macaroon_bytes, 'hex') metadata = [('macaroon',macaroon)] invoice_response = stub.AddInvoice("lnt...",metadata=metadata) payment_request = invoice_response.payment_request for payment in stub.SendPayment(payment_request): print(payment) 
Note that I've shorted the invoice code (first parameter) from Starblocks in the function "AddInvoice"

I am totally lost right now as I work myself through this file and this documentation to see which functions are available and expect which parameters. Someone stated that I would have to use the macaroon in "AddInvoice" and I don't even know why or what that is.

I try to setup two nodes in the future to create and pay invoices of each other to stresstest the speed of routing and the payment itself. I know this has been done before but I need that data from my own test for an exam.
Sorry to bother you and I would read myself into it but the data is due in two days and the stress is not helping me understand.
(Damn procrastination)
Thanks guys!
€: sendpayment via shell is no problem at all!
submitted by snt1991 to lightningnetwork [link] [comments]

Biased Nonce Sense: Lattice Attacks against Weak ECDSA Signatures in Cryptocurrencies

Cryptology ePrint Archive: Report 2019/023
Date: 2019-01-08
Author(s): Joachim Breitner, Nadia Heninger

Link to Paper


Abstract
In this paper, we compute hundreds of Bitcoin private keys and dozens of Ethereum, Ripple, SSH, and HTTPS private keys by carrying out cryptanalytic attacks against digital signatures contained in public blockchains and Internet-wide scans. The ECDSA signature algorithm requires the generation of a per-message secret nonce. This nonce must be generated perfectly uniformly, or else an attacker can exploit the nonce biases to compute the long-term signing key. We use a lattice-based algorithm for solving the hidden number problem to efficiently compute private ECDSA keys that were used with biased signature nonces due to multiple apparent implementation vulnerabilities.

References
  1. The most repeated r value on the blockchain. https://bitcointalk.org/index.php?topic=1118704.0 (2015)
  2. Bitcoin wiki: Address reuse. https://en.bitcoin.it/wiki/Address reuse (2018)
  3. Akavia, A.: Solving hidden number problem with one bit oracle and advice. In: Halevi, S. (ed.) Advances in Cryptology - CRYPTO 2009. pp. 337–354. Springer Berlin Heidelberg, Berlin, Heidelberg (2009)
  4. Bartoletti, M., Lande, S., Pompianu, L., Bracciali, A.: A general framework for blockchain analytics. In: Proceedings of the 1st Workshop on Scalable and Resilient Infrastructures for Distributed Ledgers. pp. 7:1–7:6. SERIAL ’17, ACM, New York, NY, USA (2017). https://doi.org/10.1145/3152824.3152831, http://doi.acm.org/10.1145/3152824.3152831
  5. Benger, N., van de Pol, J., Smart, N.P., Yarom, Y.: “Ooh aah... just a little bit”: A small amount of side channel can go a long way. In: Batina, L., Robshaw, M. (eds.) Cryptographic Hardware and Embedded Systems – CHES 2014. pp. 75–92. Springer Berlin Heidelberg, Berlin, Heidelberg (2014)
  6. Boneh, D., Venkatesan, R.: Hardness of computing the most significant bits of secret keys in diffie-hellman and related schemes. In: Koblitz, N. (ed.) Advances in Cryptology — CRYPTO ’96. pp. 129–142. Springer Berlin Heidelberg, Berlin, Heidelberg (1996)
  7. Bos, J.W., Halderman, J.A., Heninger, N., Moore, J., Naehrig, M., Wustrow, E.: Elliptic curve cryptography in practice. In: Christin, N., Safavi-Naini, R. (eds.) Financial Cryptography and Data Security. pp. 157–175. Springer Berlin Heidelberg, Berlin, Heidelberg (2014)
  8. Brengel, M., Rossow, C.: Identifying key leakage of bitcoin users. In: Bailey, M., Holz, T., Stamatogiannakis, M., Ioannidis, S. (eds.) Research in Attacks, Intrusions, and Defenses. pp. 623–643. Springer International Publishing, Cham (2018)
  9. Brown, D.R.L.: SEC 2: Recommended elliptic curve domain parameters. http://www.secg.org/sec2-v2.pdf (2010)
  10. Buterin, V.: Ethereum: A next-generation smart contract and decentralized application platform. https://github.com/ethereum/wiki/wiki/White-Paper (2013)
  11. Castellucci, R., Valsorda, F.: Stealing bitcoin with math (2016), https://news.webamooz.com/wp-content/uploads/bot/offsecmag/151.pdf
  12. Chen, Y., Nguyen, P.Q.: BKZ 2.0: Better lattice security estimates. In: ASIACRYPT. Lecture Notes in Computer Science, vol. 7073, pp. 1–20. Springer (2011)
  13. Courtois, N.T., Emirdag, P., Valsorda, F.: Private key recovery combination attacks: On extreme fragility of popular bitcoin key management, wallet and cold storage solutions in presence of poor rng events. Cryptology ePrint Archive, Report 2014/848 (2014), https://eprint.iacr.org/2014/848
  14. Dall, F., De Micheli, G., Eisenbarth, T., Genkin, D., Heninger, N., Moghimi, A., Yarom, Y.: Cachequote: Efficiently recovering long-term secrets of SGX EPID via cache attacks. IACR Transactions on Cryptographic Hardware and Embedded Systems 2018(2), 171–191 (May 2018). https://doi.org/10.13154/tches.v2018.i2.171-191, https://tches.iacr.org/index.php/TCHES/article/view/879
  15. De Mulder, E., Hutter, M., Marson, M.E., Pearson, P.: Using Bleichenbacher’s solution to the hidden number problem to attack nonce leaks in 384-bit ECDSA. In: Bertoni, G., Coron, J.S. (eds.) Cryptographic Hardware and Embedded Systems - CHES 2013. pp. 435–452. Springer Berlin Heidelberg, Berlin, Heidelberg (2013) Biased Nonce Sense 17
  16. Dierks, T., Rescorla, E.: The Transport Layer Security (TLS) protocol. IETF RFC RFC5246 (2008)
  17. Durumeric, Z., Adrian, D., Mirian, A., Bailey, M., Halderman, J.A.: A search engine backed by Internet-wide scanning. In: 22nd ACM Conference on Computer and Communications Security (Oct 2015)
  18. Heninger, N., Durumeric, Z., Wustrow, E., Halderman, J.A.: Mining your Ps and Qs: Detection of widespread weak keys in network devices. In: Proceedings of the 21st USENIX Security Symposium (Aug 2012)
  19. Howgrave-Graham, N.A., Smart, N.P.: Lattice attacks on digital signature schemes. Designs, Codes and Cryptography 23(3), 283–290 (Aug 2001). https://doi.org/10.1023/A:1011214926272, https://doi.org/10.1023/A:1011214926272
  20. Klyubin, A.: Some SecureRandom thoughts. https://android-developers.googleblog.com/2013/08/some-securerandom-thoughts.html (August 2013)
  21. Lenstra, A.K., Lenstra, H.W., Lovasz, L.: Factoring polynomials with rational coefficients. MATH. ANN 261, 515–534 (1982)
  22. Michaelis, K., Meyer, C., Schwenk, J.: Randomly Failed! The State of Randomness in Current Java Implementations. In: CT-RSA. vol. 7779, pp. 129–144. Springer (2013)
  23. Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system. http://bitcoin.org/bitcoin.pdf (2009)
  24. National Institute of Standards and Technology: FIPS PUB 180-2: Secure Hash Standard (Aug 2002)
  25. National Institute of Standards and Technology: FIPS PUB 186-4: Digital Signature Standard (DSS) (Jul 2013)
  26. Nguyen, P.Q., Shparlinski, I.E.: The insecurity of the elliptic curve digital signature algorithm with partially known nonces. Designs, Codes and Cryptography 30(2), 201–217 (Sep 2003). https://doi.org/10.1023/A:1025436905711, https://doi.org/10.1023/A:1025436905711
  27. Nguyen, P.Q., Stehl´e, D.: LLL on the average. In: Hess, F., Pauli, S., Pohst, M. (eds.) Algorithmic Number Theory. pp. 238–256. Springer Berlin Heidelberg, Berlin, Heidelberg (2006)
  28. Pollard, J.M.: Monte Carlo methods for index computation (mod p). In: Mathematics of Computation. vol. 32 (1978)
  29. Pornin, T.: Deterministic usage of the digital signature algorithm (DSA) and elliptic curve digital signature algorithm (ECDSA). https://tools.ietf.org/html/rfc6979 (2013)
  30. rico666: Large bitcoin collider. https://lbc.cryptoguru.org/
  31. Schnorr, C.P.: A hierarchy of polynomial time lattice basis reduction algorithms. Theor. Comput. Sci. 53(2-3), 201–224 (Aug 1987). https://doi.org/10.1016/0304-3975(87)90064-890064-8), http://dx.doi.org/10.1016/0304-3975(87)90064-890064-8)
  32. Schnorr, C.P., Euchner, M.: Lattice basis reduction: Improved practical algorithms and solving subset sum problems. Math. Program. 66(2), 181–199 (Sep 1994). https://doi.org/10.1007/BF01581144, http://dx.doi.org/10.1007/BF01581144
  33. Schwartz, D., Youngs, N., Britto, A.: The Ripple protocol consensus algorithm. https://ripple.com/files/ripple consensus whitepaper.pdf (2014), https://ripple.com/files/ripple consensus whitepaper.pdf, accessed: 2016-08-08
  34. Shanks, D.: Class number, a theory of factorization, and genera. In: Proc. of Symp. Math. Soc., 1971. vol. 20, pp. 41–440 (1971)
  35. Team, B.: Android wallet security update. https://blog.blockchain.com/2015/05/28/android-wallet-security-update/
  36. The Sage Developers: SageMath, the Sage Mathematics Software System (Version 8.1) (2017), http://www.sagemath.org
  37. Valsorda, F.: Exploiting ECDSA failures in the bitcoin blockchain. Hack In The Box (HITB) (2014)
  38. Ylonen, T., Lonvick, C.: The Secure Shell (SSH) transport layer protocol. IETF RFC 4253 (2006)
submitted by dj-gutz to myrXiv [link] [comments]

A Formal Treatment of Hardware Wallets

Cryptology ePrint Archive: Report 2019/034
Date: 2019-01-14
Author(s): Myrto Arapinis, Andriana Gkaniatsou, Dimitris Karakostas, Aggelos Kiayias

Link to Paper


Abstract
Bitcoin, being the most successful cryptocurrency, has been repeatedly attacked with many users losing their funds. The industry's response to securing the user's assets is to offer tamper-resistant hardware wallets. Although such wallets are considered to be the most secure means for managing an account, no formal attempt has been previously done to identify, model and formally verify their properties. This paper provides the first formal model of the Bitcoin hardware wallet operations. We identify the properties and security parameters of a Bitcoin wallet and formally define them in the Universal Composition (UC) Framework. We present a modular treatment of a hardware wallet ecosystem, by realizing the wallet functionality in a hybrid setting defined by a set of protocols. This approach allows us to capture in detail the wallet's components, their interaction and the potential threats. We deduce the wallet's security by proving that it is secure under common cryptographic assumptions, provided that there is no deviation in the protocol execution. Finally, we define the attacks that are successful under a protocol deviation, and analyze the security of commercially available wallets.

References
  1. KeepKey. https://keepkey.com/ (2018), [Online; accessed 1-Sep-2018]
  2. Ledger Receive Attack. https://www.docdroid.net/Jug5LX3/ledger-receive-address-attack.pdf (2018), [Online; accessed 19-Sep-2018]
  3. Trezor. https://trezor.io/ (2018), [Online; accessed 1-Sep-2018]
  4. Alois, J.: Ethereum parity hack may impact eth 500.000 or 146 million (2017)
  5. Atzei, N., Bartoletti, M., Lande, S., Zunino, R.: A formal model of bitcoin transactions. Financial Cryptography and Data Security. LNCS, Springer (2018)
  6. Badertscher, C., Maurer, U., Tschudi, D., Zikas, V.: Bitcoin as a transaction ledger: A composable treatment. pp. 324–356 (2017)
  7. Bamert, T., Decker, C., Wattenhofer, R., Welten, S.: Bluewallet: The secure bitcoin wallet. In: International Workshop on Security and Trust Management. pp. 65–80. Springer (2014)
  8. Bonneau, J., Miller, A., Clark, J., Narayanan, A., Kroll, J.A., Felten, E.W.: Sok: Research perspectives and challenges for bitcoin and cryptocurrencies. In: Security and Privacy (SP), 2015 IEEE Symposium on. pp. 104–121. IEEE (2015)
  9. Canetti, R.: Universally composable security: A new paradigm for cryptographic protocols. pp. 136–145 (2001)
  10. Canetti, R.: Universally composable signatures, certification and authentication. Cryptology ePrint Archive, Report 2003/239 (2003), http://eprint.iacr.org/2003/239
  11. Canetti, R., Krawczyk, H.: Universally composable notions of key exchange and secure channels. Cryptology ePrint Archive, Report 2002/059 (2002), http://eprint.iacr.org/2002/059
  12. Garay, J., Kiayias, A., Leonardos, N.: The bitcoin backbone protocol: Analysis and applications. In: Annual International Conference on the Theory and Applications of Cryptographic Techniques. pp. 281–310. Springer (2015)
  13. Gentilal, M., Martins, P., Sousa, L.: Trustzone-backed bitcoin wallet. In: Proceedings of the Fourth Workshop on Cryptography and Security in Computing Systems. pp. 25–28. ACM (2017)
  14. Gkaniatsou, A., Arapinis, M., Kiayias, A.: Low-level attacks in bitcoin wallets. In: International Conference on Information Security. pp. 233–253. Springer (2017)
  15. Heilman, E., Kendler, A., Zohar, A.: Eclipse attacks on bitcoin’s peer-to-peer network.
  16. Hsiao, H.C., Lin, Y.H., Studer, A., Studer, C., Wang, K.H., Kikuchi, H., Perrig, A., Sun, H.M., Yang, B.Y.: A study of user-friendly hash comparison schemes. In: Computer Security Applications Conference, 2009. ACSAC’09. Annual. pp. 105–114. IEEE (2009)
  17. Huang, D.Y., Dharmdasani, H., Meiklejohn, S., Dave, V., Grier, C., McCoy, D., Savage, S., Weaver, N., Snoeren, A.C., Levchenko, K.: Botcoin: Monetizing stolen cycles. In: NDSS. Citeseer (2014)
  18. Johnson, D., Menezes, A., Vanstone, S.: The elliptic curve digital signature algorithm (ecdsa). International journal of information security 1(1), 36–63 (2001)
  19. Lim, I.K., Kim, Y.H., Lee, J.G., Lee, J.P., Nam-Gung, H., Lee, J.K.: The analysis and countermeasures on security breach of bitcoin. In: International Conference on Computational Science and Its Applications. pp. 720–732. Springer (2014)
  20. Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system (2008)
  21. Parker, L.: Bitcoin stealing malware evolves again. https://bravenewcoin.com/news/bitcoin-stealing-malware-evolves-again/ (2016), [Online; accessed 1-Sep-2018]
  22. Pass, R., Seeman, L., Shelat, A.: Analysis of the blockchain protocol in asynchronous networks. In: Annual International Conference on the Theory and Applications of Cryptographic Techniques. pp. 643–673. Springer (2017)
  23. Penard, W., van Werkhoven, T.: On the secure hash algorithm family. Cryptography in Context pp. 1–18 (2008)
  24. Tan, J., Bauer, L., Bonneau, J., Cranor, L.F., Thomas, J., Ur, B.: Can unicorns help users compare crypto key fingerprints? In: Proceedings of the 2017 CHI Conference on Human Factors in Computing Systems. pp. 3787–3798. ACM (2017)
  25. Uzun, E., Karvonen, K., Asokan, N.: Usability analysis of secure pairing methods. In: International Conference on Financial Cryptography and Data Security. pp. 307–324. Springer (2007)
  26. Vasek, M., Bonneau, J., Ryan Castellucci, C.K., Moore, T.: The bitcoin brain drain: a short paper on the use and abuse of bitcoin brain wallets. Financial Cryptography and Data Security, Lecture Notes in Computer Science. Springer (2016)
  27. Volotikin, S.: Software attacks on hardware wallets. Black Hat USA 2018 (2018)
  28. Wuille, P.: Hierarchical Deterministic Wallets. https://en.bitcoin.it/wiki/BIP_0032 (2018), [Online; accessed 1-Sep-2018]
submitted by dj-gutz to myrXiv [link] [comments]

ECDSA Playground

ECDSA Playground
ECDSA Playground https://8gwifi.org/ecsignverify.jsp

Elliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners.
This tool is capable of generating key the the curve


https://preview.redd.it/9fwcnzijrgu11.png?width=1127&format=png&auto=webp&s=a4f36c49b74f3122b2bc903f7582c17ea041dec1
"c2pnb272w1", "c2tnb359v1", "prime256v1", "c2pnb304w1", "c2pnb368w1", "c2tnb431r1", "sect283r1", "sect283k1", "secp256r1", "sect571r1", "sect571k1", "sect409r1", "sect409k1", "secp521r1", "secp384r1", "P-521", "P-256", "P-384", "B-409", "B-283", "B-571", "K-409", "K-283", "K-571", "brainpoolp512r1", "brainpoolp384t1", "brainpoolp256r1", "brainpoolp512t1", "brainpoolp256t1", "brainpoolp320r1", "brainpoolp384r1", "brainpoolp320t1", "FRP256v1", "sm2p256v1" 
secp256k1 refers to the parameters of the elliptic curve used in Bitcoin’s public-key cryptography, and is defined in Standards for Efficient Cryptography (SEC)
A few concepts related to ECDSA:
  • private key: A secret number, known only to the person that generated it. A private key is essentially a randomly generated number. In Bitcoin, a private key is a single unsigned 256 bit integer (32 bytes).
  • public key: A number that corresponds to a private key, but does not need to be kept secret. A public key can be calculated from a private key, but not vice versa. A public key can be used to determine if a signature is genuine (in other words, produced with the proper key) without requiring the private key to be divulged.
  • signature: A number that proves that a signing operation took place.
Openssl Generating EC Keys and Parameters
$ openssl ecparam -list_curves secp256k1 : SECG curve over a 256 bit prime field secp384r1 : NIST/SECG curve over a 384 bit prime field secp521r1 : NIST/SECG curve over a 521 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field 
An EC parameters file can then be generated for any of the built-in named curves as follows:
$ openssl ecparam -name secp256k1 -out secp256k1.pem $ cat secp256k1.pem -----BEGIN EC PARAMETERS----- BgUrgQQACg== -----END EC PARAMETERS----- 
To generate a private/public key pair from a pre-eixsting parameters file use the following:
$ openssl ecparam -in secp256k1.pem -genkey -noout -out secp256k1-key.pem $ cat secp256k1-key.pem -----BEGIN EC PRIVATE KEY----- MHQCAQEEIKRPdj7XMkxO8nehl7iYF9WAnr2Jdvo4OFqceqoBjc8/oAcGBSuBBAAK oUQDQgAE7qXaOiK9jgWezLxemv+lxQ/9/Q68pYCox/y1vD1fhvosggCxIkiNOZrD kHqms0N+huh92A/vfI5FyDZx0+cHww== -----END EC PRIVATE KEY----- 
Examine the specific details of the parameters associated with a particular named curve
$ openssl ecparam -in secp256k1.pem -text -param_enc explicit -noout Field Type: prime-field Prime: 00:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:fe:ff: ff:fc:2f A: 0 B: 7 (0x7) Generator (uncompressed): 04:79:be:66:7e:f9:dc:bb:ac:55:a0:62:95:ce:87: 0b:07:02:9b:fc:db:2d:ce:28:d9:59:f2:81:5b:16: f8:17:98:48:3a:da:77:26:a3:c4:65:5d:a4:fb:fc: 0e:11:08:a8:fd:17:b4:48:a6:85:54:19:9c:47:d0: 8f:fb:10:d4:b8 Order: 00:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff: ff:fe:ba:ae:dc:e6:af:48:a0:3b:bf:d2:5e:8c:d0: 36:41:41 Cofactor: 1 (0x1) 
submitted by anish2good to u/anish2good [link] [comments]

Zero-knowledge atomic cross-blockchain swaps - feedback requested / peer review

I posted a scheme here a few days ago for trading cryptocurrencies across blockchains using zero-knowledge proofs. Unfortunately, I realized only hours after posting it that the refund protocol was completely flawed and caused a double-spend / race condition window when trying to claim refunds. I've since thought of a new scheme that I think solves these problems using much the same premise only this time I've moved the shared secret into the TX outputs and moved refunds into time-locked ECDSA keys.
Please let me know if this new scheme has any flaws.
Outline:
Alice wishes to sell her Dogecoins for Bob's Bitcoins using only standard transactions. The scheme starts by constructing a multi-sig on both blockchains that uses a timelocked ECDSA key from a timechain to provide fail-safe refunds. The multi-sig looks like this:
Alice's Dogecoin multi-sig (multi-sig-1; 3 of 4): alice, alice, bob, timechain (+60 mins)
Bob's Bitcoin multi-sig (multi-sig-2; 3 of 4): bob, bob, alice, timechain (+30 mins)
Both parties deposit their coins in the respective multi-sig. At this point if the other side doesn't proceed with the protocol the time-locked ECDSA key allow the owner to eventually claim their coins at a future point in time and due to the construction of a timechain -- a trusted setup phase is still required to generate the chain though after that point no one needs to hold any ECDSA private keys.
The protocol then proceeds like this, using zero-knowledge proofs of SHA256 hashed (partial) serialized TXs to validate TXIDs.
  1. Alice: creates a transaction (alice-to-bob) paying bob the coins from multi-sig-1. TX contains an output for a fraction of the coins going to a hidden address (scriptPubKey) and the rest to Bob.
  2. Alice: Signs alice-to-bob. Produces a zero-knowledge sha256 proof that validates the TXID she signed (the proof doesn't need to reveal the secret output, obviously.)
  3. Alice: creates a transaction (bob-to-alice) paying alice the coins from multi-sig-2. TX contains an output for a fraction of the coins going to the same hidden address and the rest to Alice.
  4. Alice: Produces a zero-knowledge sha256 proof that validates bob-to-alice TXID, proving that it contains the same secret output used for alice-to-bob and produces the stated TXIDs.
  5. Alice: gives alice-to-bob-sig, alice-to-bob-txid, alice-to-bob-proof, bob-to-alice-txid, bob-to-alice-proof.
  6. Bob: checks all the signatures and proofs are correct.
  7. Bob: signs bob-to-alice-txid.
  8. Bob: gives bob-to-alice-sig to Alice.
  9. Alice: fills in the full TX hex for bob-to-alice by using her knowledge of the secret output and broadcasts it. This simultaneously reveals the knowledge needed for Bob to produce a full serialized version of alice-to-bob allowing him to redeem alice-to-bob regardless of what Alice tries to do.
Attacks:
  1. Alice waits until the timelock encrypted ECDSA keys are just about to expire for the multi-sigs and claims a refund for her coins. She then broadcasts bob-to-alice at the same time.
  2. Alice bakes the SNARK public parameters for the proving / verifying key pairs, allowing her to produce false proofs.
Solution:
  1. Make Bob's multi-sig key unlock before Alice's. If no alice-to-bob or bob-to-alice TXs have been broadcast long before Bob's key unlocks then Bob claims his refund. Alice doesn't wait until after Bob's key has expired to broadcast any transactions since this also opens up a double-spend window. Thus, if no TXs are broadcasted and confirmed before Bob's key expires -- both parties are forced to wait to claim their refunds.
  2. Setup general-purpose keys that can be used by anyone prior to releasing the exchange. Zerocash have mentioned ways to make the generation of public parameters more secure. https://z.cash/blog/snark-parameters.html
Besides how crazy this whole scheme is, are there any obvious flaws in doing this?
submitted by Uptrenda to Bitcoin [link] [comments]

InterValue: Analysis Of A New Anti-quantum Attack Cipher Algorithm

InterValue: Analysis Of A New Anti-quantum Attack Cipher Algorithm
https://preview.redd.it/50gpnoe1wdl11.jpg?width=900&format=pjpg&auto=webp&s=c636ddc4a1c49658cba067084009e557a113b8a8

InterValue aims to provide a global value Internet infrastructure. In response to deal with various problems that existing in the present blockchain infrastructure, InterValue optimizes the protocol and mechanism of blockchain technology at all levels, which can achieve the support agreement of value transmission network. At present, the InterValue 2.0 testnet has been released, we designed and implemented a new HashNet consensus mechanism. Transaction speed within one single shard exceeds 280,000 TPS and 4 million TPS for the whole network. Security (anti-quantum attack characteristics) is undoubtedly the highlight of InterValue under the goal of establishing a low-level infrastructure for the whole field of ecology.
What is the quantum attack?
Quantum computing is a new way of building computers—using the quantum properties of particles to perform operations on data, it is probably the same way as traditional computers. In some cases, the amount of algorithmic acceleration is unusual. It is this characteristics that makes some difficult problems that exist in the electronic computer environment become easy to calculate in the quantum computer. This superior computing power of quantum computers has influenced the security of existing public key cryptography which based on computational complexity. This is the quantum attack.
What does anti-quantum attack mean?
Algorithms have always been the underlying core of blockchain technology. Most of the current algorithms are unable to withstand quantum attacks. It means that all the information of the user will be exposed to the quantum computer. If you have an anti-quantum attack algorithm, it means that the personal information is safe, at least with current technology, it cannot be cracked. Anti-quantum attack algorithms mean security. The impact of quantum attacks on digital currencies is devastating. Quantum attacks directly disrupt existing information security systems. Quantum attacks will expose the assets in the digital industry, including the benefits of mining; the keys to your wallet will be cracked and the wallet will no longer be secure. Totally, the existing security system will be disintegrated. Therefore, it is imperative to develop anti-quantum attack algorithms in advance. It is a necessary technical means to firmly protect the privacy of users.
InterValue uses a new anti-quantum attack cryptographic algorithm at the anti-quantum attack level. By replacing the ECDSA signature algorithm with the NTRUsign signature algorithm that based on the integer lattice, and replacing the existing SHA series algorithm with the Keccak-512 hash algorithm, the speed, and threats of the rapid quantum computation decrease.

Adopt NTRUsign digital signature algorithm
Current ECDSA signature algorithm
The current blockchain mainly uses the ECDSA digital signature algorithm based on elliptic curve. The signature algorithm: First, the public-private key pair needs to be generated, the private key user keeps it, the public key can be distributed to other people; secondly, the private key pair can be used and a specific message is signed; finally, the party that owns the signature public key is able to verify the signature. ECDSA has the advantages of small system parameters, fast processing speed, small key size, strong anti-attack and low bandwidth requirements. However, the quantum computer can implement a very efficient SHOR attack algorithm by ECDSA signature algorithm, and the ECDSA signature algorithm cannot resist the quantum attack.
Adopt new NTRUsign-251 signature algorithm
At present, the public key cryptosystem against quantum SHOR algorithm attacks mainly includes public key cryptography that based on lattice theory, code-based public key system represented by McEliece public key cryptosystem and multivariate polynomial represented by MQ public key cryptography. The security of McEliece public key cryptosystem is based on the error correction code problem, which is strong in security but low in computational efficiency. The MQ public key cryptosystem, that is, the multivariate quadratic polynomial public key cryptosystem, based on the intractability of the multivariate quadratic polynomial equations on the finite field, has obvious disadvantages in terms of security. In contrast, the public key encryption system based on lattice theory is simple, fast, and takes up less storage space. InterValue uses the signature algorithm based on the lattice theory NTRUSign-251. The specific implementation process of the algorithm is as follows:

https://preview.redd.it/byyzx8k3wdl11.png?width=762&format=png&auto=webp&s=d454123cabbe730271b66362a55e17b861ad50b4
It has been proved that the security of the NTRUSign-251 signature algorithm is ultimately equivalent to finding the shortest vector problem in a 502-dimensional integer lattice, but the SHOR attack algorithm for the shortest vector problem in the lattice is invalid, and there is no other fast solutions under the quantum computer. The best heuristic algorithm is also exponential, and the time complexity of attacking NTRUSign-251 signature algorithm is about 2168. Therefore, InterValue uses NTRUSign-251 algorithm that can resist SHOR algorithm attack under quantum computing.

Adopt Keccak512 hash algorithm
The common anti-quantum hash algorithm
The most effective attack methods for hash algorithm under quantum computer is GROVER algorithm, which can reduce the attack complexity of Hash algorithm from O (2^n) to O (2^n/2). Therefore, the current bit adopts the Hash algorithm PIREMD160 whose output length is only 160 bits, under this circumstance, quantum attacks algorithm used in the currency system is not safe. An effective way of resisting quantum attacks is to reduce the threat of the GROVER algorithm by increasing the output length of the Hash algorithm. It is generally believed that the Hash algorithm can effectively resist quantum attacks as long as the output length of the hash algorithm is not less than 256 bits. In addition to the threat of quantum attacks, a series of hash functions that are widely used in practice, such as MD4, MD5, SHA-1, and HAVAL, are attacked by traditional methods such as differential analysis, modulo difference, and message modification methods. Therefore, blockchains’ Hash algorithm also needs to consider the resistance of traditional attacks.
Winning the hash algorithm Keccak512
Early blockchain projects such as Bitcoin, Litecoin, and Ethereum used SHA series Hashing algorithms that exist design flaws (but not fatal). Recently, new blockchain projects have been adopted by the National Institute of Standards and Technology. The SHA-3 plan series algorithm is a new Hash algorithm.
InterValue adopts the SHA-3 plan's winning algorithm Keccak512, which contains many latest design concepts and ideas of hash function and cryptographic algorithm. It is simple in design, which is convenient for hardware implementation. The algorithm was submitted by Guido Bertoni, Joan Daemen, Michael Peters, and Giles Van Assche in October 2008. The Keccak512 algorithm uses a standard sponge structure that maps input bits of arbitrary length into fixed-length output bits. The speed is fast, with an average speed of 12.5 cycles per byte under the Intel Core 2 processor.

https://preview.redd.it/z0nnrjp4wdl11.jpg?width=724&format=pjpg&auto=webp&s=bef29aafeb1ef74b21bacb6db3f07987bf0a7ba5
As shown in the figure, in the absorption phase of the sponge structure, each message packet is XORed with the r bits inside the state, and then encapsulated into 1600 bits of data together with the fixed c bits to perform the round function f processing, and then into the squeeze. In the extrusion phase, a hash of n-bit fixed output length can be generated by iterating 24 cycles. Each loop R has only the last step round constant, but the round constant is often ignored in collision attacks. The algorithm proved to have good differential properties, and until now third-party cryptanalysis did not show that Keccak512 has security weaknesses. The first type of original image attack complexity for the Keccak512 algorithm under quantum computer is 2^256, and the second type of original image attack complexity for the Keccak512 algorithm is 2^128, so InterValue combined with the Keccak512 algorithm can resist the GROVER algorithm attack under quantum computing.

Written in the end
Quantum computing has gone through 40 years from the theory to practice. From the emergence to the present, it has entered the stage of quantitative change to qualitative change in technology accumulation, business environment, and performance improvement. For the blockchain, the most deadly part is not investor's doubt, but the accelerated development of quantum computers. In the future, quantum computers are most likely to subvert the traditional technical route of classical computing and have a larger field of development. We are sympathetic to its destructive power to the existing blockchain, and we look forward to helping the entire blockchain industry to shape a new ecosystem. On the occasion of entering the new "quantum era, trusting society", the InterValue team believes that only by fully understanding the essence of quantum cryptography (quantum communication) and anti-quantum cryptography, can we calmly stand on a high level and arrange the outline.
submitted by intervalue to InterValue [link] [comments]

MaxCoin Specifications. Important

Quick Technicals
Cryptography Tech Spec
MaxCoin uses the Keccak (SHA-3) hashing algorithm for its Proof-of-Work. Keccak was selected as an alternative to the NSA designed SHA256 after a 5-year long competition held by the NIST and will be seen increasingly as the algorithm used in banking and other secure applications. A single round of Keccak is used, resulting in a 256 bit hash.
We have also implemented a provably-secure signing algorithm, EC-Schnorr. Every existing cryptocurrency uses the ECDSA algorithm, as chosen by Satoshi; whilst ECDSA is in common use and is secure, EC-Schnorr is provably more secure and is currently being recommended over it (https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report/at_download/fullReport). Additionally, MaxCoin changes the elliptic curve utilised within the signing algorithms from a Koblitz curve, secp256k1, to a more secure psuedo-random one, secp256r1. The use of the latter curve is recommended almost universally - and the decision by Satoshi to use the former is one that is often queried in the Bitcoin world. One theory is that there are some speed advantages to using the Koblitz curve, but, the implementation used in Bitcoin (OpenSSL) does not make use of this optimisation and, thus, the result is reduced-security.
The cryptography choices within MaxCoin have been made to maximise security and, where possible, to minimise NSA influence. We have been advised throughout by the renowed cryptography expert Professor Nigel Smart (https://en.wikipedia.org/wiki/Nigel_Smart_(cryptographer)).
These changes also lay the foundation for some key features we're aiming to implement in MaxCoin over the coming months, so while they may currently appear uninteresting changes they pave the way for our future growth.
What do you mean by "Starting Algorithm"?
This is an issue of hardware miner resistance, such as ASICs. Keccak is the starting algorithm for MaxCoin and at this point in time no hardware miner currently exists. However, creating a Keccak ASIC is not impossible. Therefore, in order to protect against a hardware-miner future we are going to implement an "ASIC protection" feature into MaxCoin. This will work by allowing the blockchain to decide a new hashing algorithm for MaxCoin every x blocks. More specifically, the last authenticated transaction's hash is used to determine an integer and depending on this value an algorithm will be selected. This will mean hardware miners will find it difficult to create hardware in enough time to see profitable return. Purely for example, these could be:
x Algorithm 0 Keccak 1 Blake 2 Grostlx2 3 JH 4 Skein 5 Blake2 6 JH(Grostl) 7 Keccak+Blake
Difficulty & Distribution
MaxCoin will have a zero % premine, proven by the timestamps of the first blocks in a block explorer, and we have attempted to combat low-difficulty instamining with a fast retarget rate up until block 200. At block 200 the Kimoto Gravity Well implementation will take over the retargeting.
Mining is done via CPU at release (mining guides about to be released also on this subreddit), but a GPU miner will not be far away. We've seen some versions in the works already after we released CPUminer yesterday, and while we have not yet seen a working version, this is very unlikely to take long. We'll update all official channels with Keccak GPU miner once it is available. It's also worth noting that any GPU miner created will not work after the first algorithm switch takes place.
submitted by maxcoinproject to maxcoinproject [link] [comments]

InterValue: Analysis Of A New Anti-quantum Attack Cipher Algorithm

InterValue: Analysis Of A New Anti-quantum Attack Cipher Algorithm
https://preview.redd.it/pl9ytli1smd11.jpg?width=900&format=pjpg&auto=webp&s=afd90001218bb19c252f927ef2e292cb788c9a9d
InterValue aims to provide a global value Internet infrastructure. In response to deal with various problems that existing in the present blockchain infrastructure, InterValue optimizes the protocol and mechanism of blockchain technology at all levels, which can achieve the support agreement of value transmission network. At present, the InterValue 2.0 testnet has been released, we designed and implemented a new HashNet consensus mechanism. Transaction speed within one single shard exceeds 280,000 TPS and 4 million TPS for the whole network. Security (anti-quantum attack characteristics) is undoubtedly the highlight of InterValue under the goal of establishing a low-level infrastructure for the whole field of ecology.
What is the quantum attack?
Quantum computing is a new way of building computers—using the quantum properties of particles to perform operations on data, it is probably the same way as traditional computers. In some cases, the amount of algorithmic acceleration is unusual. It is this characteristics that makes some difficult problems that exist in the electronic computer environment become easy to calculate in the quantum computer. This superior computing power of quantum computers has influenced the security of existing public key cryptography which based on computational complexity. This is the quantum attack.
What does anti-quantum attack mean?
Algorithms have always been the underlying core of blockchain technology. Most of the current algorithms are unable to withstand quantum attacks. It means that all the information of the user will be exposed to the quantum computer. If you have an anti-quantum attack algorithm, it means that the personal information is safe, at least with current technology, it cannot be cracked. Anti-quantum attack algorithms mean security. The impact of quantum attacks on digital currencies is devastating. Quantum attacks directly disrupt existing information security systems. Quantum attacks will expose the assets in the digital industry, including the benefits of mining; the keys to your wallet will be cracked and the wallet will no longer be secure. Totally, the existing security system will be disintegrated. Therefore, it is imperative to develop anti-quantum attack algorithms in advance. It is a necessary technical means to firmly protect the privacy of users.
InterValue uses a new anti-quantum attack cryptographic algorithm at the anti-quantum attack level. By replacing the ECDSA signature algorithm with the NTRUsign signature algorithm that based on the integer lattice, and replacing the existing SHA series algorithm with the Keccak-512 hash algorithm, the speed, and threats of the rapid quantum computation decrease.
Adopt NTRUsign digital signature algorithm
Current ECDSA signature algorithm
The current blockchain mainly uses the ECDSA digital signature algorithm based on elliptic curve. The signature algorithm: First, the public-private key pair needs to be generated, the private key user keeps it, the public key can be distributed to other people; secondly, the private key pair can be used and a specific message is signed; finally, the party that owns the signature public key is able to verify the signature. ECDSA has the advantages of small system parameters, fast processing speed, small key size, strong anti-attack and low bandwidth requirements. However, the quantum computer can implement a very efficient SHOR attack algorithm by ECDSA signature algorithm, and the ECDSA signature algorithm cannot resist the quantum attack.
Adopt new NTRUsign-251 signature algorithm
At present, the public key cryptosystem against quantum SHOR algorithm attacks mainly includes public key cryptography that based on lattice theory, code-based public key system represented by McEliece public key cryptosystem and multivariate polynomial represented by MQ public key cryptography. The security of McEliece public key cryptosystem is based on the error correction code problem, which is strong in security but low in computational efficiency. The MQ public key cryptosystem, that is, the multivariate quadratic polynomial public key cryptosystem, based on the intractability of the multivariate quadratic polynomial equations on the finite field, has obvious disadvantages in terms of security. In contrast, the public key encryption system based on lattice theory is simple, fast, and takes up less storage space. InterValue uses the signature algorithm based on the lattice theory NTRUSign-251. The specific implementation process of the algorithm is as follows:
https://preview.redd.it/uzuqi589smd11.png?width=762&format=png&auto=webp&s=29670c99027fdcebadca64730ef2e3862f960192
It has been proved that the security of the NTRUSign-251 signature algorithm is ultimately equivalent to finding the shortest vector problem in a 502-dimensional integer lattice, but the SHOR attack algorithm for the shortest vector problem in the lattice is invalid, and there is no other fast solutions under the quantum computer. The best heuristic algorithm is also exponential, and the time complexity of attacking NTRUSign-251 signature algorithm is about 2168. Therefore, InterValue uses NTRUSign-251 algorithm that can resist SHOR algorithm attack under quantum computing.
Adopt Keccak512 hash algorithm
The common anti-quantum hash algorithm
The most effective attack methods for hash algorithm under quantum computer is GROVER algorithm, which can reduce the attack complexity of Hash algorithm from O (2^n) to O (2^n/2). Therefore, the current bit adopts the Hash algorithm PIREMD160 whose output length is only 160 bits, under this circumstance, quantum attacks algorithm used in the currency system is not safe. An effective way of resisting quantum attacks is to reduce the threat of the GROVER algorithm by increasing the output length of the Hash algorithm. It is generally believed that the Hash algorithm can effectively resist quantum attacks as long as the output length of the hash algorithm is not less than 256 bits. In addition to the threat of quantum attacks, a series of hash functions that are widely used in practice, such as MD4, MD5, SHA-1, and HAVAL, are attacked by traditional methods such as differential analysis, modulo difference, and message modification methods. Therefore, blockchains’ Hash algorithm also needs to consider the resistance of traditional attacks.
Winning the hash algorithm Keccak512
Early blockchain projects such as Bitcoin, Litecoin, and Ethereum used SHA series Hashing algorithms that exist design flaws (but not fatal). Recently, new blockchain projects have been adopted by the National Institute of Standards and Technology. The SHA-3 plan series algorithm is a new Hash algorithm.
InterValue adopts the SHA-3 plan's winning algorithm Keccak512, which contains many latest design concepts and ideas of hash function and cryptographic algorithm. It is simple in design, which is convenient for hardware implementation. The algorithm was submitted by Guido Bertoni, Joan Daemen, Michael Peters, and Giles Van Assche in October 2008. The Keccak512 algorithm uses a standard sponge structure that maps input bits of arbitrary length into fixed-length output bits. The speed is fast, with an average speed of 12.5 cycles per byte under the Intel Core 2 processor.
https://preview.redd.it/zwfzybeasmd11.jpg?width=724&format=pjpg&auto=webp&s=e0710e7fb1f80b7aa6517a296e2cadd6a51bd4c8
As shown in the figure, in the absorption phase of the sponge structure, each message packet is XORed with the r bits inside the state, and then encapsulated into 1600 bits of data together with the fixed c bits to perform the round function f processing, and then into the squeeze. In the extrusion phase, a hash of n-bit fixed output length can be generated by iterating 24 cycles. Each loop R has only the last step round constant, but the round constant is often ignored in collision attacks. The algorithm proved to have good differential properties, and until now third-party cryptanalysis did not show that Keccak512 has security weaknesses. The first type of original image attack complexity for the Keccak512 algorithm under quantum computer is 2^256, and the second type of original image attack complexity for the Keccak512 algorithm is 2^128, so InterValue combined with the Keccak512 algorithm can resist the GROVER algorithm attack under quantum computing.
Written in the end
Quantum computing has gone through 40 years from the theory to practice. From the emergence to the present, it has entered the stage of quantitative change to qualitative change in technology accumulation, business environment, and performance improvement. For the blockchain, the most deadly part is not investor's doubt, but the accelerated development of quantum computers. In the future, quantum computers are most likely to subvert the traditional technical route of classical computing and have a larger field of development. We are sympathetic to its destructive power to the existing blockchain, and we look forward to helping the entire blockchain industry to shape a new ecosystem. On the occasion of entering the new "quantum era, trusting society", the InterValue team believes that only by fully understanding the essence of quantum cryptography (quantum communication) and anti-quantum cryptography, can we calmly stand on a high level and arrange the outline.
submitted by intervalue to u/intervalue [link] [comments]

Rolling UTXO set hashes | Pieter Wuille | May 15 2017

Pieter Wuille on May 15 2017:
Hello all,
I would like to discuss a way of computing a UTXO set hash that is
very efficient to update, but does not support any compact proofs of
existence or non-existence.
Much has been written on the topic of various data structures and
derived hashes for the UTXO/TXO set before (including Alan Reiner's
trust-free lite nodes [1], Peter Todd's TXO MMR commitments [2] [3],
or Bram Cohen's TXO bitfield [4]). They all provide interesting extra
functionality or tradeoffs, but require invasive changes to the P2P
protocol or how wallets work, or force nodes to maintain their
database in a normative fashion. Instead, here I focus on an efficient
hash that supports nothing but comparing two UTXO sets. However, it is
not incompatible with any of those other approaches, so we can gain
some of the advantages of a UTXO hash without adopting something that
may be incompatible with future protocol enhancements.
  1. Incremental hashing
Computing a hash of the UTXO set is easy when it does not need
efficient updates, and when we can assume a fixed serialization with a
normative ordering for the data in it - just serialize the whole thing
and hash it. As different software or releases may use different
database models for the UTXO set, a solution that is order-independent
would seem preferable.
This brings us to the problem of computing a hash of unordered data.
Several approaches that accomplish this through incremental hashing
were suggested in [5], including XHASH, AdHash, and MuHash. XHASH
consists of first hashing all the set elements independently, and
XORing all those hashes together. This is insecure, as Gaussian
elimination can easily find a subset of random hashes that XOR to a
given value. AdHash/MuHash are similar, except addition/multiplication
modulo a large prime are used instead of XOR. Wagner [6] showed that
attacking XHASH or AdHash is an instance of a generalized birthday
problem (called the k-sum problem in his paper, with unrestricted k),
and gives a O(22*sqrt(n-1)) algorithm to attack it (for n-bit
hashes). As a result, AdHash with 256-bit hashes only has 31 bits of
security.
Thankfully, [6] also shows that the k-sum problem cannot be
efficiently solved in groups in which the discrete logarithm problem
is hard, as an efficient k-sum solver can be used to compute discrete
logarithms. As a result, MuHash modulo a sufficiently large safe prime
is provably secure under the DL assumption. Common guidelines on
security parameters [7] say that 3072-bit DL has about 128 bits of
security. A final 256-bit hash can be applied to the 3072-bit result
without loss of security to reduce the final size.
An alternative to multiplication modulo a prime is using an elliptic
curve group. Due to the ECDLP assumption, which the security of
Bitcoin signatures already relies on, this also results in security
against k-sum solving. This approach is used in the Elliptic Curve
Multiset Hash (ECMH) in [8]. For this to work, we must "hash onto a
curve point" in a way that results in points without known discrete
logarithm. The paper suggests using (controversial) binary elliptic
curves to make that operation efficient. If we only consider
secp256k1, one approach is just reading potential X coordinates from a
PRNG until one is found that has a corresponding Y coordinate
according to the curve equation. On average, 2 iterations are needed.
A constant time algorithm to hash onto the curve exists as well [9],
but it is only slightly faster and is much more complicated to
implement.
AdHash-like constructions with a sufficiently large intermediate hash
can be made secure against Wagner's algorithm, as suggested in [10].
4160-bit hashes would be needed for 128 bits of security. When
repetition is allowed, [8] gives a stronger attack against AdHash,
suggesting that as much as 400000 bits are needed. While repetition is
not directly an issue for our use case, it would be nice if
verification software would not be required to check for duplicated
entries.
  1. Efficient addition and deletion
Interestingly, both ECMH and MuHash not only support adding set
elements in any order but also deleting in any order. As a result, we
can simply maintain a running sum for the UTXO set as a whole, and
add/subtract when creating/spending an output in it. In the case of
MuHash it is slightly more complicated, as computing an inverse is
relatively expensive. This can be solved by representing the running
value as a fraction, and multiplying created elements into the
numerator and spent elements into the denominator. Only when the final
hash is desired, a single modular inverse and multiplication is needed
to combine the two.
As the update operations are also associative, H(a)+H(b)+H(c)+H(d) can
in fact be computed as (H(a)+H(b)) + (H(c)+H(d)). This implies that
all of this is perfectly parallellizable: each thread can process an
arbitrary subset of the update operations, allowing them to be
efficiently combined later.
  1. Comparison of approaches
Numbers below are based on preliminary benchmarks on a single thread
of a i7-6820HQ CPU running at 3.4GHz.
(1) (MuHash) Multiplying 3072-bit hashes mod 23072 - 1103717 (the
largest 3072-bit safe prime).
* Needs a fast modular multiplication/inverse implementation. * Using SHA512 + ChaCha20 for generating the hashes takes 1.2us per element. * Modular multiplication using GMP takes 1.5us per element (2.5us 
with a 60-line C+asm implementation).
* 768 bytes for maintaining a running sum (384 for numerator, 384 
for denominator)
* Very common security assumption. Even if the DL assumption would 
be broken (but no k-sum algorithm faster than Wagner's is found), this
still maintains 110 bits of security.
(2) (ECMH) Adding secp256k1 EC points
* Much more complicated than the previous approaches when 
implementing from scratch, but almost no extra complexity when ECDSA
secp256k1 signature validation is already implemented.
* Using SHA512 + libsecp256k1's point decompression for generating 
the points takes 11us per element on average.
* Addition/subtracting of N points takes 5.25us + 0.25us*N. * 64 bytes for a running sum. * Identical security assumption as Bitcoin's signatures. 
Using the numbers above, we find that:
24ms (2) 100ms
block takes (1) 3ms (2) 0.5ms
Note that while (2) has higher CPU usage than (1) in general, it has
lower latency when using precomputed per-transaction aggregates. Using
such aggregates is also more feasible as they're only 64 bytes rather
than 768. Because of simplicity, (1) has my preference.
Overall, these numbers are sufficiently low (note that they can be
parallellized) that it would be reasonable for full nodes and/or other
software to always maintain one of them, and effectively have a
rolling cryptographical checksum of the UTXO set at all times.
  1. Use cases
computation. This currently requires minutes of I/O and CPU, as it
serializes and hashes the entire UTXO set. A rolling set hash would
make this instant, making the whole RPC much more usable for sanity
checking.
blocks/UTXO sets.
the past few blocks (computed on the fly), a consistency check can be
done that recomputes it based on the database.
[1] https://bitcointalk.org/index.php?topic=88208.0
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013591.html
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013928.html
[5] https://cseweb.ucsd.edu/~mihipapers/inchash.pdf
[6] https://people.eecs.berkeley.edu/~daw/papers/genbday.html
[7] https://www.keylength.com/
[8] https://arxiv.org/pdf/1601.06502.pdf
[9] https://www.di.ens.f~fouque/pub/latincrypt12.pdf
[10] http://csrc.nist.gov/groups/ST/hash/sha-3/Aug2014/documents/gligoroski_paper_sha3_2014_workshop.pdf
Cheers,

Pieter
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

How do I verify a Bitcoin-signed message in an Ethereum contract?

My goal is to write a contract that only works if given a correctly signed Bitcoin message from a certain address, so that I can use something like a Trezor for security. Eventually there will be good security solutions that are native to Ethereum, but for now it would be useful to piggyback on Bitcoin tech.
I'm fairly certain it's possible, but I realize that I don't understand Bitcoin's implementation well enough to figure out exactly how.
I know that in Solidity you can use ecrecover to get the public key used to make an ECDSA signature. The parameters for that function are explained here (though v appears to be a uint8 now, rather than a byte).
A Bitcoin signature is just an encoded representation of exactly those parameters, as far as I understand it. I think I can use something like pybitcointools' decode_sig function to recover the raw values. For example:
>>> pybitcointools.decode_sig('H0UjW31WOLdVZZCE+fQwaH/honCQCVJLvm1mg2TYxfOcciAZYd65R7zQMywiOcM59hId/0FEgLUZRxZng3WbGDo=') (31, 31272057637503704337433930211787056015999720279051208127937379615301318341532L, 51620379026794321664809482102608597150139617930615450949468697903762876602426L) 
I tried using those things together in a Solidity contract that looks like this:
contract BitcoinSignature { address public result; function get_pub_key(string msg, uint8 v, bytes32 r, bytes32 s) { result = ecrecover(sha256(msg), v, r, s); } } 
However, I get the following error in my geth logs (twice, actually) when I test it:
EC RECOVER FAIL: v, r or s value invalid 
And while there's a result returned, it isn't consistent between different messages signed with the same key. (Edit: Although it appears to be the same for a given message when it's signed by different keys. Just in case that gives someone a hint as to what's going on.)
It seems likely that I just have something wrong with one of the conversion steps. If anyone knows this stuff better than me, please help me debug!
submitted by Semiel to ethereum [link] [comments]

Bitcoin security

Secp256k1 refers to the parameters of the ECDSA curve used in Bitcoin Ref. It is considered not safe according to Safecurves - any thoughts?
submitted by otatew to btc [link] [comments]

elliptic curve secp256k1 vulnerability?

to preface I have never used bitcoin so i don't know if this is a true vulnerability but in doing some background on bitcoin cryptology I saw something that seemed a little odd. On their protocol specification wiki they say that in their scripts they provide hexidecimal decompressed x,y coordinates (though these are really r,s values) for the signature of a transaction encoded in DER. They also specify that the curve used is the secp256k1 ECDSA curve and they go so far as to post the secp256k1 parameters p,a,b,G,n, and h on one of their wiki pages for the curve (though these can be found on the EJBCA site too). On the wikipedia page for the Elliptic curve DSA it describes calculating (r,s) as follows
  1. Calculate e=HASH(m), where HASH is a cryptographic hash function, such as SHA-1 (in bitcoin sha256).
  2. Let Z be the Ln leftmost bits of e, where Ln is the bit length of the group order n.
  3. Select a random integer k from [1, n-1].
  4. Calculate the curve point (x1,y1) = k *G (where G is the base-point).
  5. Calculate r= x1 mod(n). If r=0, go back to step 3.
  6. Calculate s= k-1(z+r(da)). If ,r=0 go back to step 3.
  7. The signature is the pair (r,s).
since they provide the signature (r,s) values for a transaction as well as the value of n, couldn't one theoretically convert the (r,s) from DER to ASN.1 then compute the k scalar by iteratively scaling the x-coordinate of G with a variable c such that c*G (mod n)=x, c++ until x is equal to r? If k is obtained the value of da can be algebraically determined and y1 could be determined, which from my understanding is the user's private key... i think? I know that n is a large number and this would require a bit of brute force but it feels like someone with a reasonable number theory background could find some paths to get around that issue. I also feel like this is too big of a loophole for bitcoin to not realize or anybody for that matter and so I'd love to know what I'm misunderstanding.
submitted by jsunderland323 to Bitcoin [link] [comments]

10-08 06:12 - 'klcchain' (self.Bitcoin) by /u/klcchain removed from /r/Bitcoin within 47-57min

'''
1 Basic knowledge of cryptography 1.1 Basic knowledge of elliptic curves 1.1.1Elliptic curve profile Let denote a finite domain, an elliptic curve defined in it, actually this curve represented as a set of points, defines an operation on elliptic curve, and two points on the elliptic curve, a + = for the two point addition operation. The intersection of the line and the curve represented by the point, and the point on the elliptic curve of the symmetry. At this point, when = when, the intersection of the tangent and the curve is represented as the point on the axis of the elliptic curve. Thus, the Abel group is formed on the finite field (+ +), and the addition unit element is. 1.1.2 Signature algorithm Defines an elliptic curve called [()) and its base point, which is the order. For the curve @ (), make a public key pair, in which the private key is the public key and can be made public. Step1: first, using Hash function to calculate the plaintext message, the Hash function algorithm used MD5 algorithm or SHA-1 algorithm can calculate the plaintext message value = (Step2); then in the interval [1, and the private key a random integer as the signature of a range of 1]; Step3: calculation a public key =;Step4: = = K, where K is the abscissa of the public key and, if = 0, returns to Step2; Step5: = = Q/ (+), which is the private key of the sender A, and if = 0, returns to Step2; Step6: the sender A transmits the message signature (to) to the receiver B. The receiver receives the message signature (B,), the specific verification process to sign the message as follows: Step1: firstly, message signature and verification, i.e. whether it is in the interval [1, N1] positive integer range, if the signature does not comply with the signature of the message, that message signature received (,) is not a valid legal signature; Step2: according to the signature public key of the sender A, the sender A and the receiver B have the same Hash function digest value, and the digest value of the signed message is calculated (=); Step3: calculates the parameter value = Q/; Step4: calculates the parameter value = = Step5: calculates the parameter value = = Step6: calculates the parameter value = +; Step7: if = 0, the receiver B may deny the signature. Otherwise, calculate '= K', where K is the parameter A horizontal coordinate; a signature. The digital signature based on ECC, partly because this scheme can avoid the order operation in the inverse operation, so it is better than the signature scheme based on discrete logarithm algorithm should be simple; on the other hand it is because the calculation of the plaintext message () (,) than the calculation simple, so its speed Schnorr digital signature scheme is faster than. Therefore, the digital signature scheme based on elliptic curve cryptography has good application advantages in resisting attack security strength, key length, computation speed, computation cost and bandwidth requirement. 1.2 Threshold key sharing technology 1.2.1 Shamir Threshold key sharing concept Threshold key sharing technology solves the key security management problem. The design of modern cryptography system is that depends on the security of cryptosystem in the cryptographic key leakage means the lost security system, so the key management plays an important role in the research and design of security in cryptography. Especially when multiple stakeholders manage an account, the key of the account is trusted, and it is very difficult to distribute it safely to multi-party participants. To solve this problem, the Israeli cryptographer Shamir proposed Shamir (,) the concept of threshold secret sharing: the key is divided into portions assigned to participants, each participant to grasp a key share, only collect more than key share, can the key recovery. 1.2.2 Linear secret sharing mechanism Linear secret sharing is the generalization of Shamir threshold key sharing. Its essence is that both the primary key space, the sub key space and the random input set are linear spaces, and the key reconstruction function is linear. The formal definition is as follows: let be a finite domain, PI is a key access structure sharing system, is the main key space. We say that Pi is a linear key sharing system, if the following conditions are met: 1) sub key is linear space, namely for, constant B, the sub key space B cd. Remember - B, e (,) as the components of B CD vector space is received, this component is dependent on the primary key and the random number 2) each authorization set may obtain the master key by means of a linear combination of sub keys, that is, for any one delegate The right to set in, constant {b, e:, B, less than 1 and less than or equal to b}, such that for any master key and random number, All = KD and l /jejcd B, e, B (E, II). 1.2.3 Shamir Polynomial interpolation threshold secret sharing scheme Shamir combines the characteristics of polynomials over finite fields and the theory of Lagrange's reconstructed polynomial, designs a threshold key management scheme based on Lagrange interpolation polynomial, and the scheme is as follows 1.3 Secure multi-party computation 1.3.1 The background of secure multiparty computation With the rapid development of Internet, more and more applications require cooperative computing among network users. But because of privacy protection and data security considerations, the user does not want to participate in collaborative computing and other users to calculate data sharing, this problem leads to collaborative computing cannot be performed, which leads to efficient use and share some of the scenarios can not be difficult to achieve the cyber source. Secure multi-party computation (secure multi-party computation) makes this problem easy to solve, and it provides a theoretical basis for solving the contradiction between data privacy protection and collaborative computing. Secure multi-party computation is the theoretical foundation of distributed cryptography, and also a basic problem of distributed computing. Secure multi-party computation means that in a non trusted multi-user network, two or more users can cooperate with each other to execute a computing task without leaking their private input information. In brief, secure multi-party computation refers to a set of people, such as /...... Q, computing functions together safely,...... , q = (/),...... (Q). Where the input of this function is held by the participant secretly, the secret input of B is B, and after the calculation, B gets the output B. Here is the safety requirements of cheating participants even in some cases, to ensure the correctness of the calculated results, which is calculated after the end of each honest participant B can get the correct output of B, but also requires each participant to ensure confidentiality of input, namely each participant B (B, b) in addition. Don't get any other information. Secure multi-party computation has been rich in theoretical results and powerful tools. Although its practical application is still in its infancy, it will eventually become an indispensable part of computer security. 1.3.2 Classification of secure multiparty computation protocols At present, secure multi-party computation protocols can be divided into four categories according to the different implementations: L secure multi-party computation protocol based on VSS sub protocol Most of the existing secure multi-party computation protocols adopt verifiable key sharing VSS (Verifiable Secret) (Sharing) the sub protocol is the basis of protocol construction, which is suitable for computing functions on any finite field. The finite field of arbitrary function can be expressed as the domain definition of addition and multiplication of the directed graph, so long as can secure computing addition and multiplication, we can calculate each addition and multiplication to calculate any function over finite fields. L secure multi-party computation protocol based on Mix-Match The secure multi-party computation protocol based on VSS sub protocol can compute arbitrary functions, but it can not efficiently calculate Boolean functions. Therefore, another secure multi-party protocol called Mix-Match is proposed. The basic idea of this protocol is that participants use secret sharing schemes to share the system's private key, and the system's public key is open. During the protocol, the participants randomly encrypt their own input public key y, then publish their own encryption results, and finally make all participants gain common output through Mix-Match. L secure multi-party computation protocol based on OT OT based secure multi-party computation protocol for computing arbitrary bit functions. It implements with "OT sub Protocol" and (and), or (or) "," (not) "three basic operations, then the arbitrary bit operation function is decomposed into a combination of three basic operations, finally by using iterative method to calculate the bit operation function. L secure multi-party computation based on homomorphic encryption Homomorphic encryption, secure multi-party computation can resist active attacks based on it is the idea of the selected atom is calculated, the calculation can be decomposed into a sequence of atomic computing allows arbitrary function and atomic calculation of input and output using homomorphic encryption, to get the final results in the encrypted state, only a specific set of participants will be able to the calculation results decrypted plaintext. 1.4 Introduction to ring signature In 2001, Rivest et al proposed a new signature technique, called Ring Signature, in the context of how to reveal the secret anonymously. Ring signature can be regarded as a kind of special group signature (Group Signature), because the establishment process need the trusted center and security group signature, often there are loopholes in the protection of anonymous (signer is traceable to the trusted center), group signature and ring signature in the foundation process in addition to the establishment of a trusted center and security. For the verifier, the signer is completely anonymous, so ring signature is more practical. Since the self ring signature was proposed, a large number of scholars have discovered its important value, such as elliptic curve, threshold and other ring signatures Volume design and development can be divided into four categories: 1. threshold ring signature 2. associated ring signature 3. revocable anonymous ring signature 4. deniable ring signature for block chain contract intelligent token transactions privacy, we use a linkable ring signature, in order to achieve privacy and prevent double problem. 2 A secure account generation scheme based on secure multi-party computation and threshold key sharing 2.1 Basic operations of secure multi-party computation The addition and multiplication, inverse element into three basic operations on the finite field, any computation can be decomposed into a sequence of the finite field addition and multiplication, inverse element, so long as to complete the three basic operations of multi-party computation, so the calculation process can be arbitrary finite domains through multi-party computation the basic operation to iterate the agreement. In this paper, we introduce a secure multi-party computation algorithm for finite fields based on secret sharing scheme based on Lagrange interpolation polynomial. 2.1.1 Addition In the secret sharing scheme based on Lagrange interpolation polynomial, the need to identify a polynomial, a shared secret is the constant term of this polynomial, and the secret share was value of this polynomial at a certain point. It is possible to set and share two secrets, the corresponding polynomials are w and X, and the secret share of participant B is b = w, B = X. In order to get the secret share of secret +, the participant B needs to construct a polynomial so that the constant of the polynomial is +, and B can be calculated. The construction process is as follows: B and B share a secret dreams and secrets, and the corresponding polynomial for W and X L = w + W / +. + W, oQ/oQ/ = {x + / +, +. X, oQ/oQ/ Might as well define = w + x = = w + x = B + B It was - 1 polynomial, and the constant term is +, for this polynomial in value * b = as + secret secret share Secure multi-party computation algorithm obtained by adding the above construction process: Addition of multi-party computation algorithms: secret, secret share, B, B output: Secret + secret share B 1)B = B + B 2.1.2 multiplication Set up two secrets, the corresponding polynomials are w and X, and the secret share of participant B is b = w, B = X. If the participants directly in the local computing B and B share a secret product, although the calculation after sharing secret is the constant term polynomials, but the degree of the polynomial is 2 (- 1), so the need to reduce the number of polynomial. The W and X share the secret share of the participant B, and the product of W and X is: Wx = w = x + / +. + (oQ/), (oQ/) Wx x = w, 1 = 1 + 1 = 2. Represented by matrices: - 1 When the upper coefficient matrix is written, it is obviously a nonsingular matrix, and the inverse matrix is denoted as Q/, which is a constant Number matrix. Remember (/, - - -, oQ/) is the first line of the matrix Q/, there are: /wx = 1 + - + - - oQ/wx, 2 - 1 Each participant randomly selected 2 - 1 - 1 - - - / polynomial, and, oQ/, to meet the requirements of B 0 = wx. Definition = "B, oQ/ Obviously: OQ/. 0 = b b 0 = /wx 1 + - - - 2 - 1 = oQ/wx +. B OQ/. = b b B Therefore, the secret is to share the secret and share the secret. A multi-party computation algorithm for multiplication 2.1.3 yuan inverse Set the secret of sharing, the corresponding polynomial is w, and the secret share of participant B is b = W. One yuan Inversion is refers to the participants by B B secret share calculation Q/ w (c) a secret share, but in the process of calculation Can not disclose, Q/ and secret share of the two. The calculation is as follows: Participant B selects the random number B, and selects the random polynomial B () to compute its secret share be = B () to the participant E. To accept all the secret share, e n = Q. Thus all participants share the same random number David - +q + = / s.. Using the multiplicative multi-party computation algorithm, the secret obtained by the secret share is calculated Share w, and sent to the other participants, so it can be recovered by using the Lagrange interpolation, we may assume that = . It is clear that the W - a Q/ C = n, i.e. Q/'s Secret share. 2.2 lock account generation scenarios The lock account generation scheme is an improvement on threshold key management scheme based on Lagrange interpolation polynomial. Its basic idea is that through the threshold secret sharing, all the authentication nodes generate a lock account in a centralized way, and each verification node has a share of the lock private key. This ensures that the lock account private key is distributed in the entire network in the form of the private key share, so it can be centralized management. 2.3 lock account signature scheme The lock account signature algorithm uses the ECDSA signature algorithm, because it is the current block chain project's mainstream signature algorithm, this choice can improve the system compatibility. In a locked account signature generation process, different from the original ECDSA signature algorithm, the private key and the random number to account is in the form of multi-party computation involved in ECDSA signature process; lock account signature verification process with the original ECDSA signature verification algorithm. Therefore, only the lock account signature generation process is described
'''
klcchain
Go1dfish undelete link
unreddit undelete link
Author: klcchain
submitted by removalbot to removalbot [link] [comments]

2014 02 14 - Elliptic Curve Digital Signature Algorithm in the SageMathCloud Elliptic Curve Cryptography Tutorial - Understanding ECC ... [New! Update] BTC Privatekey Finder With Python 3.0+ ECDSA ... Bitcoin 101 Elliptic Curve Cryptography Part 5 The Magic of Signing & Verifying Bitcoin ECDSA- Elliptic curve Digital Signature

coin, Elliptic Curve Digital Signature Algorithm is used to prove Bitcoin ownership, which plays a pivotal role in Bitcoin transaction. The security of Bitcoin mostly relies on the security of ECDSA algorithms. This thesis covers the steps of understanding how ECDSA works, and how it is used to create a new Bitcoin transaction. Bitcoin’s ECDSA uses the elliptic curve secp256k1 with domain parameters T = ( p , a , b , G , n , h ) where: § p = 2 256 − 2 32 − 2 9 − 2 8 − 2 7 − 2 6 − 2 4 − 1 ,is the size of the Galois field F p . Back to ECDSA and bitcoin. A protocol such as bitcoin selects a set of parameters for the elliptic curve and its finite field representation that is fixed for all users of the protocol. ECDSA and Bitcoin. For Bitcoin, we have the following parameters: Prime modulo: 2²⁵⁶ - 2³² - 2⁹ - 2⁸ - 2⁷ - 2⁶ - 2⁴ - 1 → this is a really really big number approximately equal ... The ECDSA algorithm uses an elliptic curve and a finite field to create a data signature so that third parties can verify the authenticity of the signature, and the signatory retains the exclusive ability to create a signature. In the case of Bitcoin, the data to be signed is a transfer of ownership. Who developed the ECC concept and when?

[index] [27083] [13372] [27941] [26703] [26809] [15572] [33239] [24747] [10623] [13678]

2014 02 14 - Elliptic Curve Digital Signature Algorithm in the SageMathCloud

Learn more advanced front-end and full-stack development at: https://www.fullstackacademy.com Elliptic Curve Cryptography (ECC) is a type of public key crypt... Welcome to part four in our series on Elliptic Curve Cryptography. I this episode we dive into the development of the public key. In just 44 lines of code, w... Skip navigation Sign in. Search #bitcoinPrivatekey #hotvideo #Bitcoin Python code Bib39 for finder bitcoin privatekey Buy it -- https://satoshidisk.com/pay/C8qYXr Contact Email kritcharatme... Bitcoin 101 - Elliptic Curve Cryptography - Part 4 - Generating the Public Key (in Python) - Duration: 21:22. CRI 26,257 views. 21:22.

https://zecmining.tiabiomabhu.gq