Bitcoin - ECDSA signature - Delfr

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]

Bottos 2020 Research and Development Scheme

Bottos 2020 Research and Development Scheme

https://preview.redd.it/umh8ivbsua841.png?width=554&format=png&auto=webp&s=5c16d9d9e61503e4c9d44212eecd176eda11550a
As 2020 is now here, Bottos has solemnly released its “2020 Research and development scheme”. On one hand, we adhere to the principle of transparency so that the whole community can comprehend our next step as a whole, but more importantly, it also helps our whole team to think deeply about the future and reach consensus. It is strongly believed that following these consistent follow-ups will help us to in order to achieve the best results.
Based on the efficient development of Bottos, the team’s technical achievements in consensus algorithms and smart contracts are used to deeply implement and optimize the existing technical architecture. At the same time using the community’s technical capabilities, horizontal development, expanding new functional modules and technical directions it stays closely integrated with the whole community.
In the future, we will keep on striving to achieve in-depth thinking, comprehensive planning, and flexible adjustment.


Overview of Technical Routes

https://preview.redd.it/rk9tpg2uua841.png?width=554&format=png&auto=webp&s=77e607b81f31c0d20feaa90eca81f09a23addca4
User feedback within the community is the driving force behind Bottos progress. In the development route of the community and industry we have formulated a roadmap for technical development, pointing out the right path for the team towards the right direction among the massive routes of modern technology.
As part of our 2020 research and development objective we have the following arrangements:
1. Intensifying enormous number of smart contracts and related infrastructures
After many years of development, smart contracts have gradually become the core and standard function in blockchain projects. The strength of smart contracts, ease of use, and stability represent the key capabilities of a blockchain project. As a good start, Bottos has already made great progress in the field of smart contracts. In smart contracts we still need to increase development efforts, making the ease of use and stability of smart contracts the top priority of our future development.
Reducing the barriers for developers and ordinary users to use, shortening the contract development cycle and saving users time is another important task for the team to accomplish. To this end, we have planned an efficient and easy-to-use one-stop contract development, debugging, and deployment tool that will provide multiple access methods and interfaces to the test network to support rapid deployment and rapid debugging.
2. Establishing an excellent client and user portal
The main goal here is to add an entrance point to the creation and deployment of smart contracts in the wallet client. To this end, the wallet needs to be transformed, a local compiler for smart contracts must be added, and an easy-to-use UI interface can be provided for the purpose of creating, deploying, and managing contracts to meet the needs of users with a single mouse click only.
3. Expanding distributed storage
Distributed storage is another focus of our development in the upcoming year. Only by using a distributed architecture can completely solve the issue of performance and scalability of stand-alone storage. Distributed storage suitable for blockchain needs to provide no less than single machine performance, extremely high availability, no single point of failure, easy expansion, and strong consistent transactions. These are the main key points and difficulties of Bottos in field of distributed storage in the upcoming days.
4. Reinforcing multi party secured computing
Privacy in computing is also a very important branch to deal with. In this research direction, Bottos has invested a lot of time and produced many research results on multi-party secured computing, such as technical articles and test cases. In the future, we will continue to give efforts in the direction of multi-party secured computing and apply mature technology achievements into the functions of the chain.

2020 Bottos — Product Development

Support for smart contract deployment in wallets
The built-in smart contract compiler inside the wallet supports compilation of the smart contracts in all languages provided by Bottos and integrates with the functions in the wallet. It also supports one-click deployment of the compiled contract source code in the wallet.
When compiling a contract, one can choose whether to pre-execute the contract code. If pre-execution is selected, it will connect to the remote contract pre-execution service and return the execution result to the wallet.
When deploying a contract, one can choose to deploy to the test network or main network and the corresponding account and private key of the test network or main network should be provided.

2020 Bottos-Technical Research

https://preview.redd.it/x2k65j7xua841.png?width=553&format=png&auto=webp&s=a40eae3c56b664c031b3db96f608923e670ff331
1. Intelligent smart contract development platform (BISDP)
The smart contract development platform BISDP is mainly composed of user-oriented interfaces, as well as back-end compilation and deployment tools, debugging tools, and pre-execution frameworks.
The user-oriented interface provides access methods based on WEB, PC, and mobile apps, allowing developers to quickly and easily compile and deploy contracts and provide contract template management functions. It can also manage the contract remotely by viewing the contract execution status, the consumed resources and other information.
In the compilation and deployment tool a set of smart contract source code editing, running, debugging, and deployment solutions as well as smart contract templates for common tasks are provided, which greatly reduces the threshold for developers to learn and use smart contracts. At the same time, developers and ordinary users are provided with a smart contract pre-execution framework, which can check the logical defects and security risks in smart contracts before actual deployment and promptly remind users a series of problems even before the smart contracts are actually run.
In the debugging tool, there are built-in local debugging and remote debugging tools. Multiple breakpoints can be set in the debugging tool. When the code reaches the breakpoint, one can view the variables and their contents in the current execution stack. One can also make conditional breakpoints based on the value of the variable. The code will not execute until the value reaches a preset value in memory.
In the pre-execution framework, developers can choose to pre-execute contract code in a virtual environment or a test net, checking out problems in some code that cannot be detected during compilation time and perform deeper code inspection. The pre-execution framework can also prompt the user in advance about the time and space resources required for execution.
2. Supporting Python and PHP in BVM virtual machine for writing smart contracts
We have added smart contract writing tools based on Python and PHP languages. These languages can be compiled into the corresponding BVM instruction set for implementation. These two reasons are used as the programming language for smart contracts.
For the Python language, the basic language elements supported by the first phase are:
- Logic control: If, Else, Eli, While, Break, method calls, for x in y
- Arithmetic and relational operators: ADD, SUB, MUL, DIV, ABS, LSHIFT, RSHIFT, AND, OR, XOR, MODULE, INVERT, GT, GTE, LT, LTE, EQ, NOTEQ
-
Data structure:
- Supports creation, addition, deletion, replacement, and calculation of length of list data structure
- Supports creation, append, delete, replace, and calculation of length of dict data structure
Function: Supports function definition and function calls
For the PHP language, the basic language elements supported by the first phase are :
- Logic control: If, Else, Eli, While, Break, method calls
- Arithmetic and relational operators: ADD, SUB, MUL, DIV, ABS, LSHIFT, RSHIFT, AND, OR, XOR, MODULE, INVERT, GT, GTE, LT, LTE, EQ, NOTEQ
Data structure:
- Support for creating, appending, deleting, replacing, and calculating length of associative arrays
Function: Supports the definition and calling of functions
For these two above mentioned languages, the syntax highlighting and code hinting functions are also provided in BISDP, which is very convenient for developers to debug any errors.
3. Continuous exploration of distributed storage solutions
Distributed storage in blockchain technology actually refers to a distributed database. Compared with the traditional DMBS, in addition to the ACID characteristics of the traditional DBMS, the distributed database also provides the high availability and horizontal expansion of the distributed system. The CAP principle of distributed system reveals that for a common distributed system there is an impossible triangle, only two of them can be selected among its three directions, consistency, availability, and partition fault tolerance. Distributed databases in China must require strong consistency. This is due to the characteristics of the blockchain system itself, because it needs to provide reliable distributed transaction capabilities. For these technical issues, before ensuring that the distributed storage solution reaches 100% availability, we will continue to invest more time and technical strength, do more functional and performance testing, and conduct targeted tests for distributed storage systems.
4. Boosting secured multi-party computing research and development
Secured multi-party Computing (MPC) is a cryptographic mechanism that enables multiple entities to share data while protecting the confidentiality of the data without exposing the secret encryption key. Its performance indicators, such as security and reliability are important for the realization of the blockchain. The transparent sharing of the data privacy on the distributed ledger and the privacy protection of the client wallet’s private key are truly essential.
At present, the research and development status of the platform provided by Bottos in terms of privacy-enhanced secured multi-party computing is based on the BIP32 / 44 standard in Bitcoin wallets to implement distributed management of client wallet keys and privacy protection.
Considering the higher level of data security and the distributed blockchain account as the public data of each node, further research and development are being planned on:
(1) Based on RSA, Pailliar, ECDSA and other public key cryptosystems with homomorphic attributes, as well as the GC protocol, OT protocol, and ZKP protocol to generate and verify transaction signatures between two parties;
(2) Introduce the international mainstream public key system with higher security and performance, national secret public key encryption system, and fewer or non-interactive ZKP protocols to achieve secured multi-party computing with more than two parties, allowing more nodes to participate Privacy protection of ledger data.

Summary

After years of exploration, we are now full of confidence in our current research and development direction. We are totally determined to move forward by continuous hard work. In the end, all members of Bottos also want to thank all the friends in the community for their continuous support and outstanding contributions. Your certainty is our greatest comfort and strongest motivation.

Be smart. Be data-driven. Be Bottos.
If you aren’t already in our group, please join now! https://t.me/bottosofficial
Join Our Community and Stay Updated!
Bottos Website | Twitter |Facebook | Telegram | Reddit
submitted by BOTTOS_AI to Bottos [link] [comments]

Technical: Pay-to-contract and Sign-to-contract

What's this? I don't make a Technical post for a month and now BitPay is censoring the Hong Kong Free Press? Shit I'm sorry, it's all my fault for not posting a Technical post regularly!! Now posting one so that we have a censorship-free Bitcoin universe!
Pay-to-contract and sign-to-contract are actually cryptographic techniques to allow you to embed a commitment in a public key (pay-to-contract) or signature (sign-to-contract). This commitment can be revealed independently of the public key / signature without leaking your private key, and the existence of the commitment does not prevent you from using the public key / signature as a normal pubkey/signature for a normal digital signing algorithm.
Both techniques utilize elliptic curve homomorphism. Let's digress into that a little first.

Elliptic Curve Homomorphism

Let's get an oversimplified view of the maths involved first.
First, we have two "kinds" of things we can compute on.
  1. One kind is "scalars". These are just very large single numbers. Traditionally represented by small letters.
  2. The other kind is "points". These are just pairs of large numbers. Traditionally represented by large letters.
Now, an "Elliptic Curve" is just a special kind of curve with particular mathematical properties. I won't go into those properties, for the very reasonable reason that I don't actually understand them (I'm not a cryptographer, I only play one on reddit!).
If you have an Elliptic Curve, and require that all points you work with are on some Elliptic Curve, then you can do these operations.
  1. Add, subtract, multiply, and divide scalars. Remember, scalars are just very big numbers. So those basic mathematical operations still work on big numbers, they're just big numbers.
  2. "Multiply" a scalar by a point, resulting in a point. This is written as a * B, where a is the scalar and B is a point. This is not just multiplying the scalar to the point coordinates, this is some special Elliptic Curve thing that I don't understand either.
  3. "Add" two points together. This is written as A + B. Again, this is some special Elliptic Curve thing.
The important part is that if you have:
A = a * G B = b * G Q = A + B 
Then:
q = a + b Q = q * G 
That is, if you add together two points that were each derived from multiplying an arbitarry scalar with the same point (G in the above), you get the same result as adding the scalars together first, then multiplying their sum with the same point will yield the same number. Or:
a * G + b * G = (a + b) * G 
And because multiplication is just repeated addition, the same concept applies when multiplying:
a * (b * G) = (a * b) * G = (b * a) * G = b * (a * G) 
Something to note in particular is that there are few operations on points. One operation that's missing is "dividing" a point by a point to yield a scalar. That is, if you have:
A = a * G 
Then, if you know A but don't know the scalar a, you can't do the below:
a = A / G 
You can't get a even if you know both the points A and G.
In Elliptic Curve Cryptography, scalars are used as private keys, while points are used as public keys. This is particularly useful since if you have a private key (scalar), you can derive a public key (point) from it (by multiplying the scalar with a certain standard point, which we call the "generator point", traditionally G). But there is no reverse operation to get the private key from the public key.

Commitments

Let's have another mild digression.
Sometimes, you want to "commit' to something that you want to keep hidden for now. This is actually important in some games and so on. For example, if you are paying a game of Twenty Questions, one player must first write the object they are thinking of, then fold or hide it in such a way that what they wrote is not visible. Then, after the guessing player has asked twenty questions to narrow down what the object is and has revealed what he or she thinks the object being guessed was, the guessee reveals the object by unfodling and showing the paper.
The act of writing down commits you to the specific thing you wrote down. Folding the paper and/or hiding it, err, hides what you wrote down. Later, when you unfold the paper, you reveal your commitment.
The above is the analogy to the development of cryptographic commitments.
  1. First you select some thing --- it could be anything, a song, a random number, a promise to deliver products and services, the real identity of Satoshi Nakamoto.
  2. You commit to it by giving it as input to a one-way function. A one-way function is a function which allows you to get an output from an input, but after you perform that there is no way to reverse it and determine the original input knowing only the final output. Hash functions like SHA are traditionally used as one-way functions. As a one-way function, this hides your original input.
  3. You give the commitment (the output of the one-way function given your original input) to whoever wants you to commit.
  4. Later, when somebody demands to show what you committed to (for example after playing Twenty Questions), you reveal the commitment by giving the original input to the one-way function (i.e. the thing you selected in the first step, which was the thing you wanted to commit to).
  5. Whoever challenged you can verify your commitment by feeding your supposed original input to the same one-way function. If you honestly gave the correct input, then the challenger will get the output that you published above in step 3.

Salting

Now, sometimes there are only a few possible things you can select from. For example, instead of Twenty Questions you might be playing a Coin Toss Guess game.
What we'd do would be that, for example, I am the guesser and you the guessee. You select either "heads" or "tails" and put it in a commitment which you hand over to me. Then, I say "heads" or "tails" and have you reveal your commitment. If I guessed correctly I win, if not you win.
Unfortunately, if we were to just use a one-way function like an SHA hash function, it would be very trivial for me to win. All I would need to do would be to try passing "heads" and "tails" to the one-way function and see which one matches the commitment you gave me. Then I can very easily find out what your committed value was, winning the game consistently. In hacking, this can be made easier by making Rainbow Tables, and is precisely the technique used to derive passwords from password databases containing hashes of the passwords.
The way to solve this is to add a salt. This is basically just a large random number that we prepend (or append, order doesn't matter) to the actual value you want to commit to. This means that not only do I have to feed "heads" or "tails", I also have to guess the large random number (the salt). If the possible space of large random numbers is large enough, this prevents me from being able to peek at your committed data. The salt is sometimes called a blinding factor.

Pay-to-contract

Hiding commitments in pubkeys!
Pay-to-contract allows you to publish a public key, whose private key you can derive, while also being a cryptographic commitment. In particular, your private key is also used to derive a salt.
The key insight here is to realize that "one-way function" is not restricted to hash functions like SHA. The operation below is an example of a one-way function too:
h(a) = a * G 
This results in a point, but once the point (the output) is known, it is not possible to derive the input (the scalar a above). This is of course restricted to having the input be a scalar only, instead of an arbitrary-length message, but you can add a hash function (which can accept an arbitrary-length input) and then make its output (a fixed-length scalar) as the scalar to use.
First, pay-to-contract requires you to have a public and private keypair.
; p is private key P = p * G ; P is now public key 
Then, you have to select a contract. This is just any arbitrary message containing any arbitrary thing (it could be an object for Twenty Questions, or "heads" or "tails" for Coin Toss Guessing). Traditionally, this is symbolized as the small letter s.
In order to have a pay-to-contract public key, you need to compute the below from your public key P (called the internal public key; by analogy the private key p is the internal private key):
Q = P + h(P | s) * G 
"h()" is any convenient hash function, which takes anything of arbitrary length, and outputs a scalar, which you can multiply by G. The syntax "P | s" simply means that you are prepending the point P to the contract s.
The cute thing is that P serves as your salt. Any private key is just an arbitrary random scalar. Multiplying the private key by the generator results in an arbitrary-seeming point. That random point is now your salt, which makes this into a genuine bonafide hiding cryptographic commitment!
Now Q is a point, i.e. a public key. You might be interested in knowing its private key, a scalar. Suppose you postulate the existence of a scalar q such that:
 Q = q * G 
Then you can do the below:
 Q = P + h(P | s) * G Q = p * G + h(P | s) * G Q = (p + h(P | s)) * G 
Then we can conclude that:
 q = p + h(P | s) 
Of note is that somebody else cannot learn the private key q unless they already know the private key p. Knowing the internal public key P is not enough to learn the private key q. Thus, as long as you are the only one who knows the internal private key p, and you keep it secret, then only you can learn the private key q that can be used to sign with the public key Q (that is also a pay-to-contract commitment).
Now Q is supposed to be a commitment, and once somebody else knows Q, they can challenge you to reveal your committed value, the contract s. Revealing the pay-to-contract commitment is done by simply giving the internal public key P (which doubles as the salt) and the committed value contract s.
The challenger then simply computes:
P + h(P | s) * G 
And verifies that it matches the Q you gave before.
Some very important properties are:
  1. If you reveal first, then you still remain in sole control of the private key. This is because revelation only shows the internal public key and the contract, neither of which can be used to learn the internal private key. So you can reveal and sign in any order you want, without precluding the possibility of performing the other operation in the future.
  2. If you sign with the public key Q first, then you do not need to reveal the internal public key P or the contract s. You can compute q simply from the internal private key p and the contract s. You don't even need to pass those in to your signing algorithm, it could just be given the computed q and the message you want to sign!
  3. Anyone verifying your signature using the public key Q is unaware that it is also used as a cryptographic commitment.
Another property is going to blow your mind:
  1. You don't have to know the internal private key p in order to create a commitment pay-to-contract public key Q that commits to a contract s you select.
Remember:
Q = P + h(P | s) * G 
The above equation for Q does not require that you know the internal private key p. All you need to know is the internal public key P. Since public keys are often revealed publicly, you can use somebody else's public key as the internal public key in a pay-to-contract construction.
Of course, you can't sign for Q (you need to know p to compute the private key q) but this is sometimes an interesting use.
The original proposal for pay-to-contract was that a merchant would publish their public key, then a customer would "order" by writing the contract s with what they wanted to buy. Then, the customer would generate the public key Q (committing to s) using the merchant's public key as the internal public key P, then use that in a P2PKH or P2WPKH. Then the customer would reveal the contract s to the merchant, placing their order, and the merchant would now be able to claim the money.
Another general use for pay-to-contract include publishing a commitment on the blockchain without using an OP_RETURN output. Instead, you just move some of your funds to yourself, using your own public key as the internal public key, then selecting a contract s that commits or indicates what you want to anchor onchain. This should be the preferred technique rather than OP_RETURN. For example, colored coin implementations over Bitcoin usually used OP_RETURN, but the new RGB colored coin technique uses pay-to-contract instead, reducing onchain bloat.

Taproot

Pay-to-contract is also used in the nice new Taproot concept.
Briefly, taproot anchors a Merkle tree of scripts. The root of this tree is the contract s committed to. Then, you pay to a SegWit v1 public key, where the public key is the Q pay-to-contract commitment.
When spending a coin paying to a SegWit v1 output with a Taprooted commitment to a set of scripts s, you can do one of two things:
  1. Sign directly with the key. If you used Taproot, use the commitment private key q.
  2. Reveal the commitment, then select the script you want to execute in the Merkle tree of scripts (prove the Markle tree path to the script). Then satisfy the conditions of the script.
Taproot utilizes the characteristics of pay-to-contract:
  1. If you reveal first, then you still remain in sole control of the private key.
    • This is important if you take the Taproot path and reveal the commitment to the set of scripts s. If your transaction gets stalled on the mempool, others can know your commitment details. However, revealing the commitment will not reveal the internal private key p (which is needed to derive the commitment private key q), so nobody can RBF out your transaction by using the sign-directly path.
  2. If you sign with the public key Q first, then you do not need to reveal the internal public key P or the contract s.
    • This is important for privacy. If you are able to sign with the commitment public key, then that automatically hides the fact that you could have used an alternate script s instead of the key Q.
  3. Anyone verifying your signature using the public key Q is unaware that it is also used as a cryptographic commitment.
    • Again, privacy. Fullnodes will not know that you had the ability to use an alternate script path.
Taproot is intended to be deployed with the switch to Schnorr-based signatures in SegWit v1. In particular, Schnorr-based signatures have the following ability that ECDSA cannot do except with much more difficulty:
As public keys can, with Schnorr-based signatures, easily represent an n-of-n signing set, the internal public key P can also actually be a MuSig n-of-n signing set. This allows for a number of interesting protocols, which have a "good path" that will be private if that is taken, but still have fallbacks to ensure proper execution of the protocol and prevent attempts at subverting the protocol.

Escrow Under Taproot

Traditionally, escrow is done with a 2-of-3 multisignature script.
However, by use of Taproot and pay-to-contract, it's possible to get more privacy than traditional escrow services.
Suppose we have a buyer, a seller, and an escrow service. They have keypairs B = b * G, S = s * G, and E = e * G.
The buyer and seller then generate a Taproot output (which the buyer will pay to before the seller sends the product).
The Taproot itself uses an internal public key that is the 2-of-2 MuSig of B and S, i.e. MuSig(B, S). Then it commits to a pair of possible scripts:
  1. Release to a 2-of-2 MuSig of seller and escrow. This path is the "escrow sides with seller" path.
  2. Release to a 2-of-2 MuSig of buyer and escrow. This path is the "escrow sides with buyer" path.
Now of course, the escrow also needs to learn what the transaction was supposed to be about. So what we do is that the escrow key is actually used as the internal public key of another pay-to-contract, this time with the script s containing the details of the transaction. For example, if the buyer wants to buy some USD, the contract could be "Purchase of 50 pieces of United States Federal Reserve Green Historical Commemoration papers for 0.357 satoshis".
This takes advantage of the fact that the committer need not know the private key behind the public key being used in a pay-to-contract commitment. The actual transaction it is being used for is committed to onchain, because the public key published on the blockchain ultimately commits (via a taproot to a merkle tree to a script containing a MuSig of a public key modified with the committed contract) to the contract between the buyer and seller.
Thus, the cases are:
  1. Buyer and seller are satisfied, and cooperatively create a signature that spends the output to the seller.
    • The escrow service never learns it could have been an escrow. The details of their transaction remain hidden and private, so the buyer is never embarrassed over being so tacky as to waste their hard money buying USD.
  2. The buyer and seller disagree (the buyer denies having received the goods in proper quality).
    • They contact the escrow, and reveal the existence of the onchain contract, and provide the data needed to validate just what, exactly, the transaction was supposed to be about. This includes revealing the "Purchase of 50 pieces of United States Federal Reserve Green Historical Commemoration papers for 0.357 satoshis", as well as all the data needed to validate up to that level. The escrow then investigates the situation and then decides in favor of one or the other. It signs whatever transaction it decides (either giving it to the seller or buyer), and possibly also extracts an escrow fee.

Smart Contracts Unchained

Developed by ZmnSCPxj here: https://zmnscpxj.github.io/bitcoin/unchained.html
A logical extension of the above escrow case is to realize that the "contract" being given to the escrow service is simply some text that is interpreted by the escrow, and which is then executed by the escrow to determine where the funds should go.
Now, the language given in the previous escrow example is English. But nothing prevents the contract from being written in another language, including a machine-interpretable one.
Smart Contracts Unchained simply makes the escrow service an interpreter for some Smart Contract scripting language.
The cute thing is that there still remains an "everything good" path where the participants in the smart contract all agree on what the result is. In that case, with Taproot, there is no need to publish the smart contract --- only the participants know, and nobody else has to. This is an improvement in not only privacy, but also blockchain size --- the smart contract itself never has to be published onchain, only the commitment to it is (and that is embedded in a public key, which is necessary for basic security on the blockchain anyway!).

Sign-to-contract

Hiding commitments in signatures!
Sign-to-contract is something like the dual or inverse of pay-to-contract. Instead of hiding a commitment in the public key, it is hidden in the signature.
Sign-to-contract utilizes the fact that signatures need to have a random scalar r which is then published as the point R = r * G.
Similarly to pay-to-contract, we can have an internal random scalar p and internal point P that is used to compute R:
R = P + h(P | s) * G 
The corresponding random scalar r is:
r = p + h(P | s) 
The signing algorithm then uses the modified scalar r.
This is in fact just the same method of commitment as in pay-to-contract. The operations of committing and revealing are the same. The only difference is where the commitment is stored.
Importantly, however, is that you cannot take somebody else's signature and then create an alternate signature that commits to some s you select. This is in contrast with pay-to-contract, where you can take somebody else's public key and then create an alternate public key that commits to some s you select.
Sign-to-contract is somewhat newer as a concept than pay-to-contract. It seems there are not as many applications of pay-to-contract yet.

Uses

Sign-to-contract can be used, like pay-to-contract, to publish commitments onchain.
The difference is below:
  1. Signatures are attached to transaction inputs.
  2. Public keys are attached to transaction outputs.
One possible use is in a competitor to Open Timestamps. Open Timestamps currently uses OP_RETURN to commit to a Merkle Tree root of commitments aggregated by an Open Timestamps server.
Instead of using such an OP_RETURN, individual wallets can publish a timestamped commitment by making a self-paying transaction, embedding the commitment inside the signature for that transaction. Such a feature can be added to any individual wallet software. https://blog.eternitywall.com/2018/04/13/sign-to-contract/
This does not require any additional infrastructure (i.e. no aggregating servers like in Open Timestamps).

R Reuse Concerns

ECDSA and Schnorr-based signature schemes are vulnerable to something called "R reuse".
Basically, if the same R is used for different messages (transactions) with the same public key, a third party with both signatures can compute the private key.
This is concerning especially if the signing algorithm is executed in an environment with insufficient entropy. By complete accident, the environment might yield the same random scalar r in two different runs. Combined with address reuse (which implies public key reuse) this can leak the private key inadvertently.
For example, most hardware wallets will not have any kind of entropy at all.
The usual solution to this is, instead of selecting an arbitrary random r (which might be impossible in limited environments with no available entropy), is to hash the message and use the hash as the r.
This ensures that if the same public key is used again for a different message, then the random r is also different, preventing reuse at all.
Of course, if you are using sign-to-contract, then you can't use the above "best practice".
It seems to me plausible that computing the internal random scalar p using the hash of the message (transaction) should work, then add the commitment on top of that. However, I'm not an actual cryptographer, I just play one on Reddit. Maybe apoelstra or pwuille can explain in more detail.
Copyright 2019 Alan Manuel K. Gloria. Released under CC-BY.
submitted by almkglor to Bitcoin [link] [comments]

Best General RenVM Questions | September 2019

Best General RenVM Questions | September 2019 *These questions are sourced directly from Telegram

Q: Given the RenVM Mainnet Roll-out Plan, what are the differences between how Darknodes participate in the P2P Network, Consensus, and Execution within RenVM?
A: An outline of each component and its role in RenVM system is outlined below:P2P NetworkThe peer-to-peer network is used for two core purposes: peer discovery, and message saturation. Peer discovery allows Darknodes to learn about other active Darknodes in their shard, and in the network at large. Message saturation ensures that all messages sent around the network are seen by everyone.
ConsensusThe consensus engine is used to reach a strict ordering of transactions that go through RenVM. This ensures that the Darknodes powering RenVM are able to agree on what actions to take, and when.
ExecutionThe execution engine is used to run secure multiparty computations. This is how actions in RenVM are ultimately taken. These actions involve generating private keys, signing interoperability transactions, and, in the future, running general-purpose application logic. And all of this in secret.

Q: How do I shut down my current Darknode(s)?
A: Follow this instruction set explicitly and you won't have any issues: https://renproject.zendesk.com/hc/en-us/articles/360020365234-How-to-Fully-Deregister-a-Darknode

Q: Is running a Darknode on Chaosnet useful for the team?
A: Yes, by running a Chaosnet Darknode you are inherently helping us test. One of the core purposes of Chaosnet is to the real world incentives of RenVM. Running (and continuing to run) a Chaosnet Darknode says something about the incentives at play: they’re enough to get people running Darknodes. And this helps us! In fact, by not running a Chaosnet Darknode you’re also inherently helping us test. It’s telling us there’s something not quite right with the incentives.

Q: And what's the incentive for someone to collude and attack the network during Chaosnet?
A: The ability to steal real BTC/ZEC/BCH, the want to help us test the network, the want to betray their fellow colluders and take their REN bonds, and of course, some (wo)men just want to watch the world burn.

Q: All of this de-registering and re-registering for mainnet is a bit annoying, is it necessary?
A: We do certainly understand the point as it's been discussed at length but registration for the RenVM Mainnet is a necessary component (applying automatic updates for current Darknodes to run RenVM is not technically feasible). This announcement is very much an administrative piece to ensure our community has plenty of time and notice to proceed at the speed they prefer. Chasonet is designed for testing and those willing to actively experiment, but certainly not mandatory and there is no pressure on the general community to be active during this period.
In summary for those who prefer to be less active, should de-register their current Darknode(s) and wait patiently for activation at the release of Mainnet SubZero, no other action is needed.

Q: Is RenVM secure against quantum computing?
A: The core of RZL sMPC is theoretical secure. This means that no amount of compute power can break it (making it post-Q safe). There are some parts of it that are not (zkSNARKs and some hashes that aren’t known whether or not they’re post-Q safe) but these are easy to replace (with zkSTARKs and some post-Q safe hashes).
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).
In short, if a QC can steal funds from RenVM, it’s because it can steal funds from any Ethereum/Bitcoin/etc. private key.

Q: If I don't deregister my Darknode by RenVM Mainnet, will I lose my 100K REN?
A: The REN bond is safe forever. You can deregister your Darknode from the legacy Mainnet whenever. We recommend doing it now, because it can take three days, and once Chaosnet rolls around that’s where our support focus will be.

Q: When shifting in funds, say a user doesn't have eth funds and this call fails const newSigResult = await ethSig.submitToEthereum (web3.currentProvider). what is the best way for that user to pick up where they left off if they leave the web page to get some ETH, and then come back? Should the app generates a new shift in the object, override the params and gateway address objects, re-submit to RenVM, and then make the above call again? Assume the transaction info such as original params and gateway address are stored in local storage so those will be available when the user comes back.
A: This is the approach we take. We store the RenVM tx in local storage and then when the user comes back we can construct the Ethereum tx and hand it to them for signing again. You can construct the RenVM tx locally and store it before asking the user to send their BTC to the gateway to protect against unexpected shutdowns. This way, you can recover from them leaving the app at any point in the process without loss of funds. (This also allows you to resend the RenVM tx in the event that the first send fails for any reason.)

Q 1: Could you elaborate on the proportionality of (a) Total value of bonded REN (b) Total value of assets under RenVM control? Does RenVM require (b) <= (a) at all times? RenVM would need an Oracle to determine the USD value of both (a) and (b).
A 1: The oraclisation is done by the Darknodes. Each of them assesses what they determine that value of (a) and (b) to be and if 2/3rds of them independently decide (b) can be increased then the network will be able to go ahead with the computation. We do require (b) < (a) but have not determined the exact ratio. Because Darknodes are randomly sampled (and constantly reshuffled) from the entire group, this value can consider the entire amount of REN bonded (not just the REN bonded by one shard).
Q 2: There's potentially an incentive-misalignment issue here: Darknodes would want to bypass the (b) < (a) limit in order to continue to process more tx's and collect fees.
A 2: True, but there’s also a natural incentive for Darknodes to want to keep the network secure. A hack would likely render their REN to drop dramatically in price and they’re REN will be locked for 2-3 months after deregistration. This is also true of users. They should be wary of keeping assets locked up when it nears the secure threshold. This can be encouraged by scaling down the burning fees/raising minting fees to encourage the movement of funds “in the right direction”

Q: Quick question: right now, a developer can choose to wait for 0 confirmations before minting zBTC on Ethereum when shifting in real BTC. Will the RenVM network require a minimum number of bitcoin confirmations, or is that always up to the application developer? If it's up to the developer, what if the developer chooses 0 confirmations, mints zBTC, and then double spends on the bitcoin network, invalidating that original bitcoin transaction? shouldn't that invalidate the zBTC that was already minted from the original 0 conf transaction?
A: The developer cannot choose. RenVM will wait for the appropriate number of confirmations. On Testnet, this number is currently set to zero because it makes testing easier. On Mainnet, there will be systems for people to take on the “confirmation risk” and provide float. Devs can also set it up so that people can deposit ahead-of-time. We are also exploring Lightning and similar concepts.

Q: I've noticed an increase of tx's made through RenVm, how tests are going on; have you met any unexpected obstacles?
A: We’ve encountered a few issues with nodes when they are rebooted/crash (we are constantly rebooting/crashing them to make sure the network continues to operate as expected under those circumstances). But, we have fixes in the work for all these issues and it hasn’t prevented us from being able to add new features (BCash and SegWit support has recently hit Devnet and will be arriving on Testnet soon).

Q1: If home chain = destination chain, then RenVM is effectively a mixing service?
A1: It can be used that way, definitely. But, it has to have a few more privacy features enabled, shifting alone won’t do.
Q2: RenVM mints Aztec notes for example?
A2: Yep, that’s the plan; we need to wait until the Ignition ceremony before this can be done. It’s one of the next features in our pipeline though! BTC would “appear” on Ethereum with no known owner. And, if you wait an amount of time between getting the authorizing from RenVM and using the signature, then it would be impossible to trace it back to the request that went to RenVM.

Q: When I go to the Command Center, the page doesn't load?
A: One has to be on the Kovan Testnet (on Metamask). To do this, select the top middle button on your Metamask tab and click Kovan Test Network (Purple circle). If you’d like to see it in action, submit a trade on our Testnet Dex Demo (https://renproject.github.io/renvm-demo/) and see it proceed through RenVM via the Hyperdrive tab: https://dcc-testnet.republicprotocol.com/hyperdrive

Q: Mixicles & RenVM: It seems like Mixicles could be used to preserve privacy features for on and off-chain settlements in a blockchain agnostic way. Wouldn’t this be seen as a threat as smart contracts could now replace a darkpool while maintaining the element of anonymity?
A: Mixicles (and all other ZK on-chain stuff we’ve seen) gives you privacy on the chain. So you can prove things have been done right (one of the things we like about public blockchains), without exposing any information about the thing (an issue with public blockchains). But, the prover still has access to the information. This rules it out for many kinds of private apps. RenVM gives you absolute privacy. You can do things with data, and prove things about data, without anyone anywhere ever knowing anything about the data. This is much more general.

Q: Can’t people just fork RenVM?
A: What ultimately prevents forks is the network effect. All projects that want to take decentralization seriously need to open-source their implementations. Almost by definition, a decentralized network is nothing but its community of people willing to work together; this is the very essence of “trust no-one except for the majority”. If you refuse to open-source you don’t have a community, you have hostages.
Building up momentum and creating a large network and community is incredibly valuable and not something that can be forked. Bitcoin is still Bitcoin, despite the large number of forks that have been created, and most of the time forks don’t overtake or outpace the original because there is too much inertia in the original community.
There are other, less philosophical, benefits too. Open-source code means you can get more feedback, people can help fix bugs, identify potential security issues, anyone can validate the implementation, people can build their own implementations (resulting in highly desirable “N versioning” which prevents a single bug compromising all nodes).

https://renproject.zendesk.com/hc/en-us/articles/360001180915-General-RenVM-Questions-September-2019
submitted by RENProtocol to RenProject [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]

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]

Hardware Wallet Standard | Jonas Schnelli | Aug 16 2016

Jonas Schnelli on Aug 16 2016:
Hi
Unfortunately, there is no standard in how desktop- or mobile-wallets
can interact with a hardware device resulting in wallet vendors adding
plugins with proprietary code for non-standardized interfaces.
I started a BIP (extreme draft, feel free to improve language, grammar
and content) to address this missing part of the ecosystem.
I think it would be extremely helpful if @ledger, @trezor,
@voisin/@breadwallet, @electrum, @bitpay (and more?!) would help working
on a such standard.
The BIP describes two approaches how to communicate (pipe and
URI-scheme) with the signing-devices app, although, in my opinion, all
major platform do support the URI approach (maybe we could drop the pipe
approach then).
The URI approach means that there is no need to configure the
application location in order to start a inter-process(-app) communication.
Mediawiki:
https://github.com/jonasschnelli/bips/blob/8abb51f0b21b6664388f6e88f6fd642c90d25dca/bip-undef-0.mediawiki
---- BIP (rough early stage draft)
BIP: ???
Title: Detached Signing
Author: Jonas Schnelli
Status: Draft (early stage!)
Type: Standards Track
Created: 2016-08-02
== Abstract ==
This BIP describes a way how wallet applications can decouple sensitive
privatekeys from the internal keychain and interact with a
signing-devices (hardware wallet, "cold" storage) over a generic
interface in order to get signatures.
== Motivation ==
It seems like that the current approach for allowing signing-devices to
interact with third party wallets is to build a plugin [1][2][3]. Adding
plugins for each hardware wallet type will increase possible security
issues and result in multiple proprietary-third-party code within the
wallet application with very similar structures.
A generic interface how wallets can interact with signing-devices would
result in better user experience, less critical code and simpler
adaption for various signing-devices.
== Specification ==
In order to support desktop- and smartphone-wallet-applications, this
BIP describes two slightly different approaches (process pipe and URI
call) in how to interact with the signing-devices. If possible, the
modern URI approach should be chosen.
=== Signing-Device-Controller-Application ===
To allow a generic interface while still allowing different ways how to
internally communicate with the signing device itself (USB, TCP/IP,
air-gapped Qr-Code scanning, etc.) a controller-application is required.
=== General signing process ===
The wallets signing process must be according the following principal:
or message together with metadata (scriptPubKey, hd-keypath of the inputs)
signing-device-controller-application
signing-request-object, eventually shows UI, user can sign or cancel
signing-response-object with signatures or an error
creating process (example: add signatures to transaction and broadcast)
=== Desktop Process Intercommunication ===
Desktop wallets can interact with a signing device over process
intercommunication (pipe) together with a
signing-device-controller-application.
As specified below, the signing-request-object is a URI string passed
through the pipe. The desktop wallet needs to wait (with a recommended
timeout between 1 and 5 minutes) until the signing-response-object will
be sent back by the signing-device-controller-application.
=== Smartphone/URI App Intercommunication ===
Smartphones and modern operating systems are trying to sandbox
applications and interprocess communication (on pipe level) is mostly
disallowed.
On smartphones, we must use URI-schemes.
The wallet can pass information to the
signing-device-controller-application by using a predefined URI scheme.
detatchedsigning://?&returnurischeme;=
The querystring must be URI encoded.
RFC 2616 does not specify a maximum length of URIs (get request). Most
modern smartphone operating system allow URIs up to serval megabytes.
Signing complex data-structure is therefore possible.
The returnurischeme must contain a URI schema where the
result of the signing process should be returned to.
The returnurischeme must be populated and "opened" once the signing
process has been completed (or cancled).
=== Signing Request ===
The signing request is a flexible URI-Query-String that will be used by
the Signing-device-controller-application for user confirmation as well
as for creating the signature.
The URI-query-string must conform to the following format:
detatchedsigning://sign?type=&data;=&inputscripts;=,,...&inputhdkeypath;=,,...&returnscheme;=
type = type of the data to sign
data = raw unsigned bitcoin transaction or text-message
(optional)inputscripts = scriptPubKey(s) of the inputs in exact order
(optional)inputhdkeypath = hd-keypath of the inputs in exact order
(optional)returnscheme = a URI scheme where the response must be sent to
(smartphone approach)
  • inputhdkeypath or inputscripts must be provided.
=== Signing Response ===
The signing response is a flexible URI-Query-String that will be sent
back to the wallet application and must contain the signatures or an
error code.
The URI-query-string can be opened (smartphone approach) or will be sent
back though the interprocess pipe.
://signresponse?errorcode=&signatures;=,,...
In case of ECDSA, the returned signatures must be normalized compact
signatures with the size of 64bytes (128 hex chars).
==== Possible error code ====
0 = no error
1 = user canceled
2 = timeout
10 = missing key identifier (missing HD keypath or input scriptpubkey)
11 = unsupported signing type
12 = could not resolve script
50 = unknown internal error
==== Examples ====
===== Simple p2pkh transaction =====
Unsigned raw transaction:
0100000001fd3cd19d0fb7dbb5bff148e6d3e18bc42cc49a76ed2bfd7d760ad1d7907fd9ce0100000000ffffffff0100e1f505000000001976a9149062e542a78d4fe00dcf7cca89c24a8013c381a388ac00000000
(input ced97f90d7d10a767dfd2bed769ac42cc48be1d3e648f1bfb5dbb70f9dd13cfd
vout:1, output: P2PKH mtgQ54Uf3iRTc9kq18rw9SJznngvF5ryZn 1 BTC)
signing-request URI must be:
detatchedsigning://sign?type=bitcoin-p2pkh&data=0100000001fd3cd19d0fb7dbb5bff148e6d3e18bc42cc49a76ed2bfd7d760ad1d7907fd9ce0100000000ffffffff0100e1f505000000001976a9149062e542a78d4fe00dcf7cca89c24a8013c381a388ac00000000&inputscripts=76a914531148ad17fdbffd4bac72d43deea6c7cf0387d088ac&inputhdkeypath=m/0'/0'/1&returnscheme;=myapp
The inputhdkeypath is optional in this case
signing-response URI must be:
detatchedsigning://signresponse?error=0&signatures=<128hex-chars>
===== Simple a bitcoin message =====
Message: Lorem ipsum dolor sit amet
signing-request URI must be:
detatchedsigning://sign?type=bitcoinmsg&data=Lorem+ipsum+dolor+sit+amet&inputhdkeypath=m/0'/0'/2
signing-response URI must be:
detatchedsigning://signresponse?error=0&signatures=<128hex-chars>
=== Support for multiple signing-devices ===
Must operating systems allow only one registered application per
URI-scheme. To support multiple signing-devices, wallets and
signing-devices can optional add support for brand based URI-schemes.
In addition to the standard URI scheme,
signing-devices-controller-applications can register an additional URI
scheme (with the identical request/response syntax and logic) including
a brand-identifier.
Registering a brand-identifier based URI scheme without registering the
default URI scheme is not allowed.
Wallets can detect if a certain brand based URI scheme is supported and
therefore gives user a selection if multiple signing-devices where
detected [4][5].
detatchedsigning://
Supported brand-identifiers are:
  • trezor
  • ledger
  • keepkey
  • digitalbitbix
== References ==
[1] https://github.com/spesmilo/electrum/pull/1662
[2] https://github.com/spesmilo/electrum/pull/1391
[3] https://github.com/bitpay/copay/pull/3143
[4]
https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIApplication_Class/
[5]
https://developer.android.com/reference/android/content/pm/PackageManager.html
== Acknowledgements ==
== Copyright ==
This work is placed in the public domain.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/fe4471a9/attachment.sig
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013008.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Progress on Hcash's Post-Quantum R&D [Part 1]

I.Research and Design of Post-Quantum Technology Solution
1.1.Technology choice and solution design of Post-Quantum Signature:
•Security and Performance Analysis and Assessment of existing post-quantum signature solution We have carried out deep security and performance analysis and assessment of the following post-quantum signature solution such as Hash-based signature schemes: MSS (Merkle Signature Scheme), XMSS (eXended Merkle Signature Scheme), LMS, SPHINCS, NSW; Lattice-based signature schemes: GVP, LYU, GLP, BLISS, DILITHIUM, NTRU; Code-based signature schemes: CFS, QUARTZ; Multivariate-polynomial-based signature schemes: RAINBOW, etc. Compared to traditional signature solution (such as ECDSA algorithm commonly used in cryptocurrency system), post-quantum signature solution’s public key and signature are much longer. If we simply introduce post-quantum signature into existing cryptocurrency or Blockchain system, TPS will be reduced significantly. Take bitcoin for example, current TPS is 7 transactions per second. If we introduce post-quantum signature DILITHIUM, its TPS will be reduced to 0.389 transaction/second.
•In the design of Hcash post-quantum solution, we wish to achieve the following 4 features: 1) Compatibility: Compatible with existing ECDSA (Elliptic Curve Digital Signature Algorithm) signature solution; 2) Flexibility: Support multiple post-quantum signature solutions that are thoroughly analysed, assessed and proved by international cryptography research institutions, meanwhile their security and performance must be outstanding. 3) Security: the post-quantum solution must be proved secure in theory, and side-channel attack proof in practice; 4) high performance: Signing and signature verification must be fast. Most importantly, the public key and signature must be short.
•Based upon the principles described above, we have made our technology choice. On one hand, from security point of view, we have chosen Hash function based post-quantum signature solution (MSS or LMS), these solutions have weak security hypothesis and their security rely on Hash function. In another word, if the Hash function is secure, then the solution is secure. In our solution, we choose SHA-3 (that is Keccak. Keccak is chosen by NIST as international standard Hash function in October 2012). According to thorough analysis and assessment on Keccak done by international cryptography search institutions, we expect Keccak is very secure for a very long period in future. Compared to traditional computers, quantum computers do not have much advantage on attacking (collision attack, pre-image attack, secondary pre-image attack) Hash functions, which means Keccak function based MSS or LMS will have very strong security for a very long period in future. Besides, Keccak function based MSS or LMS solution is side-channel attack proof. On the other hand, from performance point of view (including signing / signature verification performance, public key / signature length), public key and signature length can significantly affect cryptocurrency or blockchain system’s TPS, therefore we have chosen Bliss whose overall performance is the best. This solution’s security is built on top of difficult mathematics problem based on LWE. Currently quantum computer does not have effective algorithm to solve the difficult math problem based on LWE. Because Bliss algorithm’s signing and signature verification performance is good, and its public key and signature length is shortest among the existing post-quantum signature algorithms, Hcash’s TPS will benefit from Bliss. To be clear, MSS, LMS and Bliss algorithms are all analysed, assessed and proved by international cryptography research institutions and their security and performance are all outstanding. (Although MSS/LMS has different security hypothesis from Bliss, their security can all be proved in theory)
•Based on the technology choice, we will adopt Keccak function based MSS or LMS (strong theoretical security and side-channel attack proof), and LWE based Bliss algorithm (theoretical security depends on LWE’s difficult math problem and its performance is the best among the existing post-quantum signature solutions). However, we still need to solve the following two critical problems:
1) public key and signature are much longer than traditional digital signature ECDSA’s public key and signature. If we implement these signature algorithms in cryptocurrency or blockchain, transaction size will increase a lot and TPS will be reduced significantly. 2) Discrete Gauss Sampling (DGS) module in Bliss algorithm has side-channel attack risk in practice. For problem 1, we propose a new SegWit (Segregated Witness) solution which solve the problem quite well.
For problem 2, there are some existing side-channel attack to Bliss algorithm. We have to point out that these attacks are difficult to implement. In the attack to multiplication calculation, the author himself points out that the attack which utilises Markov model cannot succeed if the Hamming weight acquired has relatively high level noise. In practise, Hamming weight always has some noise. When attacking sampling function with power consumption and electromagnetic information, firstly data quality will affect branch clause analysis, secondly even if data quality is high, it is difficult engineering job to accurately locate the divulge point on the curve. For the same reason, when analysing applications on the system using branch trace, although every branch clause can be recorded accurately (without noise), it is difficult to locate the attacking point among large amount of branch records. Regarding Cache attack, how to keep flush and reload happen alternatively in time series is a tough problem. It’s hard to implement without changing the source code. Although it’s very difficult to implement these side-channel attacks, we should pay enough attention to potential side-channel leaking problem in Bliss algorithm. Hence we propose effective protection solution after deeply analysing possible side-channel information leaking points in Bliss algorithm. This solution does not harm Bliss algorithm’s performance (Most importantly, the solution doesn’t change public key and signature length at all). The research outcome mentioned above will guarantee we implement highly secure and performant post-quantum feature in Hcash.
The advantages of our solutions are:
(1) Compatibility: before quantum computers come into use, cryptocurrency and blockchain systems can still use ECDSA signature solution. Our solution is compatible with existing ECDSA signature solution, hence it can not only connect with current mainstream cryptocurrency exchange platforms, but also build a foundation to support cross chain interaction in future.
(2) Flexibility: our solution supports two post-quantum signature solutions that are thoroughly analysed, assessed and proved by international cryptography research institutions. Their security and performance are both outstanding. It will provide great flexibility and sound security for Hcash
(3) Security: Our solution supports two post-quantum signature algorithms: MSS/LMS and Bliss. For MSS/LMS, its security hypothesis is weak (that is, its security only relies on the security of SHA-3 function). If SHA-3 function is secure, then the solution is secure. According to thorough analysis and assessment on Keccak done by international cryptography search institutions, we expect Keccak is very secure for a very long period in future. Compared to traditional computers, quantum computers do not have much advantage on attacking (collision attack, pre-image attack, secondary pre-image attack) Hash functions, which means Hash adopting Keccak based MSS/LMS will have very strong security for a very long period in future. Further more, Keccak based MSS/LMS solution is side-channel attack proof. For Bliss algorithm, its security is based on LWE’s difficult math problem (under this hypothesis it can be proved secure). So far quantum computers have no effective algorithms to solve LWE’s difficult math problem that Bliss algorithm relies on. Besides, we thoroughly analysed possible side-channel information leaks in Bliss algorithm and propose an innovative and effective protection solution, so that Bliss algorithm can effective prevent side-channel attack without compromising performance.
(4) High performance: our solution supports 2 post-quantum algorithms whose signing/signature verification and public key/signature length are both outstanding among existing algorithms. Because post-quantum signature solution’s public key and signature length are much longer than traditional ECDSA’s, it will increase transaction size a lot and reduce the number of transaction in each block, and reduce TPS in the end. To solve this problem, we propose an innovative SegWit scheme which can solve this problem quite well. It’s deserved to be mentioned that, our post-quantum solution integrated with our new combined consensus scheme (which is already implemented in Hcash) will materialise our absolute superiority in TPS. e.g., if we implement DILITHIUM signature in Bitcoin, its TPS is maximum 0.389 transactions / second, while if we implement our post-quantum solution, its TPS is about 150 transactions / second.
(5) Usability: our post-quantum signature solution can be used widely in existing cryptocurrency and blockchain systems.
submitted by H_cash to hcash [link] [comments]

Progress on Hcash's Post-Quantum R&D[Part 2]

Click here to read part 1. (The latter part of 1.1 Technology choice and solution design of Post-Quantum Signature) •DILITHIUM signature is another mainstream post-quantum signature solution, and it already has implementation on Github. DILITHIUM signature solution’s security is based on difficult math problem on lattice (under this hypothesis DILITHIUM is proved secure). Meanwhile, the designer says DILITHIUM algorithm can effectively prevent side-channel attack. So DILITHIUM is recommended from security point of view. However, DILITHIUM signature solution’s weakness is it public key/signature is long, the combined length is about 34Kbits (4.25KBytes). Therefore it will reduce TPS significantly if applied in cryptocurrency and blockchain systems. As mentioned before, if Bitcoin implements DILITHIUM signature solution, its TPS is maximum 0.389 transactions/second.
•Recently QRC team released their post-quantum cryptocurrency’s white paper. Let’s have a brief reading of main content: (1) It points out quantum computer can effectively attack existing bitcoin mining pool and cause these mining pool’s production reduce 10% or so. The white paper provides an outline analysis of the attacks and says these attacks will not occur until 2028. (2) It points out quantum computer can effectively attack ECDSA and provides an outline analysis. (3) It summarises solutions to the problems mentioned above and points out existing post-ASIC PoW scheme can be used to solve “quantum computer can effectively attack some mining pool” problem. Meanwhile, it reviews existing post-quantum signature solution, and briefly introduces DILITHIUM signature solution. (4) In the paper “Quantum attacks on Bitcoin, and how to protect against them”, the author doesn’t recommend any post-quantum signature solution, neither points out the problem that “existing post-quantum signature solution’s lengthy public key/signature reduces TPS significantly”. The author doesn’t provide any innovative post-quantum solution. Therefore this paper is a summary document or technical report about post-quantum feature rather than a white paper about post-quantum solution. (5) Last but not the least, we think public blockchain’s consensus evolution path can be pure PoW -> combined PoW + PoS -> pure PoS (with advantages of both existing PoW and PoS). Our research team has already started deep research on PoS. So the problem mentioned in point 1 won’t exist when cryptocurrency and blockchain system switch to pure PoS consensus scheme.
1.2. Bliss algorithm solution document (completed)
1.3. Bliss algorithm side-channel attack protection solution design (completed)
1.4. MSS/XMSS/LMS algorithm solution document (completed)
1.5. New SegWit solution design (completed)
1.6. Technical report “Post-quantum Signature Schemes in Hcash” (nearly completed)
Click here to read part 3:
submitted by H_cash to hcash [link] [comments]

I am working on a client-side encryption web app. Looking for feedback.

I am looking for feedback on the security of my encryption scheme, as well as any other general feedback.
I included a detailed description of encryption mechanism. For this reason, this post will be lengthy, please forgive me for this.
As for the web app, you can play it on: http://hiddendoc.com/
Sample usage
Visit http://hiddendoc.com/fish and enter password "fish", now you can view and edit the document. When you are done, click "Encrypt and Save" to update the document.
This is still work in progress, any kind of feedback is appreciated!
Background (you can skip this)
About 3 months ago, I suddenly had the idea of creating this web app. I knew little about cryptography and did some rough reading on various online sources. Later, I asked /crypto about the encryption scheme I was planning to use. http://www.reddit.com/crypto/comments/25avbis_this_encryption_scheme_secure_pseudocode/
To my surprise, I received many very detailed, and well written feedback. Most of them, I've adopted and used for implementing the app. However, a number of changes have been made, and I can never sure about my decisions (never taken classes in cryptography).
This is something I want to finish for both personal use and share it with other people who may find it useful.
What the app hopes to accomplish
Most of this is already written on the webpage. Basically, a user wants to privately edit a plaintext document in a web browser, save it online, and view/edit it later.
To achieve this, the data encrypted then sent to the server. When the user wants to edit the document again, the server sends back the encrypted text and it's decrypted in the browser.
Almost everything is done on the client, and the server only:
  1. Stores encrypted documents, and returns them on request.
  2. Update existing documents if the request comes from the original author.
In other words, anyone can ask the server for other people's document, but only those with passwords can decrypt/update it. Our assumption is that the user's computer is not compromised and he/she will choose a good password.
Encryption function
(For code, see JavaScript in “/static/main.js – function $scope.encrypt()”)
Edit: Based on the suggestions, I've made some updates to the encryption scheme and updated the code.
  1. User enters a . We assume this is hard to brute-force.
  2. We generate a random and run both the and though PBKDF2 with 1000 iterations to get , the is later used for ECDSA. The and any other random arrays we generate are 160 bits (assuming I read the library code correctly). Edit: is only generated on document creation. It is sent back from server for later edits.
  3. We generate a random array and then use to ECDSA to sign the with the . The signed is the . Edit: basically, the is the 'k' in step 3 for http://en.wikipedia.org/wiki/Elliptic_Curve_DSA#Signature_generation_algorithm. The hash we sign is just a static string. My assumption is that only those with the private key can generate a signature and we sue the signature as the encryption key. Edit2: As pointed out, this is a half-assed way I reinvented and I am probably better off using ECIES. Edit3:Updated: We generate the by following the steps similar to ECIES (specifically, the first 3 steps here http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme). Note that there is also a , and a value to save
  4. We encrypt the plaintext message to with . Another randomized salt created here.
  5. Each time the message is encrypted, we increase the document by 1. The is then signed using ECDSA with the , this yields the . At the same time, we multiply the with the elliptic curve generator to get the . Edit: Each time the message is encrypted, we increase the document by 1.
  6. Finally, we join , , , , , , into a single string and send that to the server. Edit: Finally, we join , ,, value from step 3 plus all the salts into a single string and sign the hash of that using ECDSA. The hash is appended to the string and that final string is sent to server
  7. If the document does not exist, the server creates and saves it. Otherwise, the server checks that: (a) The version is exactly one higher than what is stored on the server. (b) the public key did not change. (c) and the signature is correct. Finally, the server will update the document.
For decryption, the document stored on the server (containing everything list above) are sent back to the user. As long as a correct password is provided, the document can be decrypted again.
This is how the app works right now. I am using SJCL (Stanford Javascript Crypto Library) for all the encryption, kdf, and random number generation (it's a really cool library).
This encryption scheme looks okay to me, but I am not sure if it's actually secure.
Questions
  1. I am using secp256k1 as the curve right now, Is this a good choice? (I figured it's probably good because Bitcoin uses it)
  2. Is signing a randomly generated string to get AES key a good idea? Edit: This is a terrible idea and I am using the first steps described here (http://en.wikipedia.org/wiki/Integrated_Encryption_Scheme) instead of making up random stuff.
  3. Is signing the version number (e.g. a string that looks like “0000002”), to achieve authentication a good idea? Edit: this is a bad idea and we are now signing the sha256 of the (whole thing + version.)
  4. Should I add a checksum/hash? At the moment, it's possible to corrupt the document by changing the salt before uploading. Edit: Added.
  5. Right now, the length of the cipher text exposes the length of plaintext. Is this something I should worry about?
If you notice some other flaws, please point it out. Heck! if you can break the site and tell me how you did it, that will help too.
submitted by fishtastic to crypto [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]

Disclosure: consensus bug indirectly solved by BIP66 | Pieter Wuille | Jul 28 2015

Pieter Wuille on Jul 28 2015:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all,
I'd like to disclose a vulnerability I discovered in September 2014,
which became unexploitable when BIP66's 95% threshold was reached
earlier this month.

Short description:

A specially-crafted transaction could have forked the blockchain
between nodes:

Upgrade instructions:

None. Transactions that could trigger this problem have become invalid
on the network since BIP66's deployment of version 3 blocks reached 95%
on July 4th, 2015.

Long description:

The problem is related to the signature encoding rules.
Bitcoin's signatures are ASN.1 BER encoded. BER is a complex standard
that allows many different encodings for the same data. Since Bitcoin
Core 0.8, a standardness rule has been in effect that only allowed
subset of encodings (DER) for relay and mining, even though any BER
remained valid in the blockchain - at least in theory.
In practice, BER has many weird edge cases, and I have not found a
single cryptographic codebase that can parse all of them correctly.
This includes OpenSSL, Crypto++, BouncyCastle, btcec, and our own
libsecp256k1 library.
This on itself would not be a problem, as full nodes on the network
currently use OpenSSL. However, while researching what was needed to
make libsecp256k1 compatible with it, I discovered that OpenSSL is even
inconsistent with itself across different platforms.
One of the features of BER is the ability for internal structures to
have a length descriptor whose size itself is up to 126 bytes (see
X.690-0207 8.1.3.5). A 1 terabyte data structure would for example use
a 5-byte length descriptor. However, there is no requirement to use the
shortest possible descriptor, so even a 70-byte ECDSA signature could
use a 5-byte length descriptor and be valid. Unfortunately, OpenSSL
supports length descriptors only as long as their size is at most that
of a C 'long int', a type whose size depends on the platform (Windows
and 32-bit Linux/OSX have a 4-byte long int, 64-bit Linux/OSX have an
8-byte long int). See
https://github.com/openssl/openssl/blob/bfa34f551c2d38e826deb44a269cb0f720f9f63b/crypto/asn1/asn1_lib.c#L178.
Some non-OpenSSL based signature validation
systems don't support such length descriptors at all, resulting in an
extra forking risk on top for them if used for blockchain validation.
This effectively means that a block chain containing a transaction with
a valid signature using such a 5-byte length descriptor would be
accepted by some systems and not by others, resulting in a fork if it
were mined into a block.

Timeline:

signatures non-standard. No release since then would relay or mine
transactions that could trigger the vulnerability. However, such a
transaction was still valid inside blocks.
The BIP62 draft includes a rule that would make version 2 transactions
with non-DER signatures invalid.
depend on OpenSSL's specific parser, I modified the BIP62 proposal to
have its strict DER signatures requirement also apply to version 1
transactions. No non-DER signatures were being mined into blocks
anymore at the time, so this was assumed to not have any impact. See
https://github.com/bitcoin/bips/pull/90 and
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-July/006299.html.
Unknown at the time, but if deployed this would have solved the
vulnerability.
discovered the architecture dependency listed above and the associated
vulnerability. The best means to fix it at the time was by getting
BIP62 adopted.
Several proposed changes to BIP62. See
https://github.com/bitcoin/bips/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aclosed+bip62.
for CVE-2014-8275. The fix introduced a restriction on ECDSA signatures
to be strict DER, which would have solved all problems related to
signature encodings, except Bitcoin's consensus-critical nature
requires bug-for-bug compatibility between nodes. Worse, it seemed that
there was again a small (1%) number of blocks being created with
non-DER signatures in it, resulting in actual forks. The only immediate
solution that did not introduce more risk for forks was parsing and
re-encoding signatures using OpenSSL itself before verification to
bypass the restriction, making the problem persist. See
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-January/007097.html.
revealed the vulnerability, and the presence of miners not enforcing
strict DER might have made the vulnerability actually exploitable.
BIP62 was still a moving target, so we wanted a faster means to solve
this. Therefore, a new BIP was proposed with just the strict DER
requirement, numbered BIP66. This would both allow non-OpenSSL
verification, and solve the vulnerability, without needing to fix the
less urgent malleability problem that BIP62 wanted to address. See
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-January/007156.html.
BIP66. See
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007480.html.
rule for strict DER signatures in the blockchain. This solved the
vulnerability, and opens the door to using non-OpenSSL signature
verification in the near future.
Pieter Wuille
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQGcBAEBAgAGBQJVt5FGAAoJEFeJbS/48LZX3ccMAJdPrpa8ggcYEyy8naqc7ewL
1Mwv24p/6Q8+T7Q6EWmgoApY1jljF+AzgSpfaf310QZf9yuC/JC++AmHfUaa9UQG
Mq1+duX64uDWIeNKTfuCwZvU0ataARZKmFUpp60UF+VtiJyLo9tpHTVajM0lv9Oq
OX40qHVC/iBogRLNREC1ggWH1JPMTbEch50YX1bgNi3gE5gtMggSQ2OXrGCCtrvR
7cVFlIyOhlLtvSAnxzmHyY8Iol+qVhIZi4mCmDgOoQKVaiYm1cODQ+nrMHx02DKC
Wqstwb/mET/vbCX4qxSNQ2B+mQk0WO/gSrWiQkBLi/AfLBh/8A/kL1RpKxVQzoaP
O165LbXye42w8Js/sE/zT6d4CIbYaW0GpF6m4agwDYgPLomhdk/elPRojKYsEab+
oFWPVagqKI9e/pjFBxqfIv3iyx1hHB6YIaX5TfFRVjsWzag5Qi2ssQYOQymyjg4J
UHNxW0PMPAOg5KS/uFja4OWxstHhTW9G+rslEK9g==
=7F3K
-----END PGP SIGNATURE-----
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

ConceptCoin

ConceptCoin is a proof-of-concept crypto-currency. The idea is to create a currency which can be used to test out some new ideas.
The first idea is to test out an improved version of proof-of-stake which uses a trusted source of randomness to select which coin holder is able to create new blocks. The first implementation will use NIST's randomness beacon as a source of randomness.
We also want to test out ideas to stabilise the price of the crypto-currency via a blockchain based voting system and methods of monetary base inflation/deflation.
Join the team @http://www.reddit.com/Conceptcoin/
Contact me to speak about donations/funding. Would like feedback on the Protocol below.
Protocol V0.1 Draft (as drafted by telepatheic)
Introduction
To aid interoperability, development speed and to prevent programmer confusion, ConceptCoin will be based on the existing Bitcoin protocol in v0.1, subsequent versions will implement changes to increase efficiency (such as using a faster ECDSA curve) and make the protocol more consistent. The specification is based upon https://en.bitcoin.it/wiki/Protocol_specification and v0.9.1 of the bitcoin core code. Where the two are not in agreement the v0.9.1 bitcoin core code takes priority.
There will be some small changes as follows:
The magic value is F3 B2 BA D1 The relay field is removed from the version message filterload, filteradd, filterclear, merkleblock, and alert messages are not supported
There will be three major changes which will be explained in greater depth:
Scripting will be simplified Blocks will have a different structure to support proof of stake mining Beacon blocks are introduced
Scripting simplifications
The only valid scripts are those of the following form:
scriptPubKey: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG scriptSig:
Blocks
Blocks are where the most significant changes are. Blocks must be signed by the block creator. To help detect double signing of blocks in future versions, the signature is of the block hash concatenated with the magic value and the timestamp. This makes sure that signing other pieces of data can't be used as evidence of signing ConceptCoin blocks.
Block header:
Version uint32_t: as in Bitcoin = 1
Timestamp uint32_t: must be greater than the last beacon block timestamp and less than the last beacon block timestamp + 60. Default is beacon block timestamp + 30
Block creator pubKey char[33]: the block creator's public key in compressed form given as where is 0x02 if y is even and 0x03 if y is odd. (see section below)
Previous block hash char[32]: the hash of the previous valid block
Merkle tree hash char[32]: As in Bitcoin
Block hash char[32]: The SHA256 hash of the previous fields
Block hash signature char[64]: The signature for the block hash concatenated with the magic value and the timestamp.
Block body:
Number of transactions uint16_t: The number of transactions which follows (note: slight difference to Bitcoin, uses fixed length integer)
Transactions starting with the coinbase transaction (same as Bitcoin)
Creating a block
Block creators are selected by the random seed in the previous beacon block. The selection is weighted by the amount of unspent output such that it becomes proof of stake based.
All pubKeyHashes from unspent outputs (except those created in the previous block) are ordered in a database by pubKeyHash from smallest to largest alongside the cumulative (starting from the smallest pubKeyHash) amount of unspent output. We take the 512 bit random seed and find the (mod total unspent output) of this number to get a random selector. The pubKeyHash selected is the one which has the smallest cumulative value next to it where the cumulative value is greater than the random selector. Here is a simplified example:
pubKeyHash Unspent output 12 30 17 4 32 5 21 12 19 9 24 16
pubKeyHash Cumulative Value of selector required 12 30 0-29 17 34 30-33 19 43 34-42 21 55 43-54 24 71 55-70 32 76 71-75
If the random output from the beacon was 412: 412 (mod 76) = 32 so pubKeyHash 17 is selected
Because not all key holders are likely to be online, blocks will not be created every minute in v0.1 (this will be modified in subsequent versions). Also in v0.1 double signing of different blocks is technically possible creating forks. Double block signing detection will be added in subsequent versions.
Beacon block
Version uint32_t: the version of the beacon block (can be used to change to different beacon specifications) = 1
Timestamp uint32_t: must match the NIST beacon timestamp
NIST version var_str: must match the NIST beacon version string
NIST frequency uint32_t: must match the NIST beacon frequency (normally 60)
NIST seed value char[64]: must match the NIST beacon seed value
NIST status uint32_t: must match the NIST beacon status code
NIST signature char[256]: must match the NIST beacon signature
NIST output value char[64]: must match the NIST beacon output value
A beacon block is a new message with command = "beacon". It allows everyone to be aware of the last random number generated without overloading the NIST randomness beacon server. The signature signs the previous output value to link the beacon blocks together.
More details will be provided on how to verify that beacon blocks are genuine.
Transaction fees
By default transaction fees are 0.
Block rewards
Block rewards are 100 base (indivisible) units. This is an arbitrary choice and there will be no economic mechanism in v0.1
The maturation period for coinbase transactions is 10 blocks but they contribute to the pubKeyHash selection algorithm in the same way as all other transactions.
Edited to update beacon block data types.
submitted by Mox16 to altcoin [link] [comments]

"By placing a probe near a mobile device while it performs cryptographic operations, an attacker can measure enough electromagnetic emanations to fully extract the secret key that authenticates the end user's data or financial transactions."

This is an automatic summary, original reduced by 71%.
Researchers have devised an attack on Android and iOS devices that successfully steals cryptographic keys used to protect Bitcoin wallets, Apple Pay accounts, and other high-value assets.
"An attacker can non-invasively measure these physical effects using a $2 magnetic probe held in proximity to the device, or an improvised USB adapter connected to the phone's USB cable, and a USB sound card," the researchers wrote in a blog post published Wednesday.
While the researchers stopped short of fully extracting the key on a Sony-Ericsson Xperia x10 Phone running Android, they said they believe such an attack is feasible.
CoreBitcoin developers told the researchers they plan to replace their current crypto library with one that's not susceptible to the attack.
The researchers said they reported the vulnerability to OpenSSL maintainers, and the maintainers said that hardware side-channel attacks aren't a part of their threat model.
At the moment, the attack would require a hacker to have physical possession of-or at least have a cable or probe in close physical proximity to-a vulnerable mobile device while it performed enough operations to measure "a few thousand ECDSA signatures." The length of time required would depend on the specific application being targeted.
Summary Source | FAQ | Theory | Feedback | Top five keywords: attack#1 research#2 vulnerable#3 key#4 version#5
NOTICE: This thread is for discussing the submission topic only. Do not discuss the concept of the autotldr bot here.
submitted by autotldr to autotldr [link] [comments]

New attack steals secret crypto keys from Android and iOS phones

This is an automatic summary, original reduced by 71%.
Researchers have devised an attack on Android and iOS devices that successfully steals cryptographic keys used to protect Bitcoin wallets, Apple Pay accounts, and other high-value assets.
"An attacker can non-invasively measure these physical effects using a $2 magnetic probe held in proximity to the device, or an improvised USB adapter connected to the phone's USB cable, and a USB sound card," the researchers wrote in a blog post published Wednesday.
While the researchers stopped short of fully extracting the key on a Sony-Ericsson Xperia x10 Phone running Android, they said they believe such an attack is feasible.
CoreBitcoin developers told the researchers they plan to replace their current crypto library with one that's not susceptible to the attack.
The researchers said they reported the vulnerability to OpenSSL maintainers, and the maintainers said that hardware side-channel attacks aren't a part of their threat model.
At the moment, the attack would require a hacker to have physical possession of-or at least have a cable or probe in close physical proximity to-a vulnerable mobile device while it performed enough operations to measure "a few thousand ECDSA signatures." The length of time required would depend on the specific application being targeted.
Summary Source | FAQ | Theory | Feedback | Top five keywords: attack#1 research#2 vulnerable#3 key#4 version#5
NOTICE: This thread is for discussing the submission topic only. Do not discuss the concept of the autotldr bot here.
submitted by autotldr to autotldr [link] [comments]

Feedback on ConceptCoin?

ConceptCoin is a proof-of-concept crypto-currency. The idea is to create a currency which can be used to test out some new ideas.
The first idea is to test out an improved version of proof-of-stake which uses a trusted source of randomness to select which coin holder is able to create new blocks. The first implementation will use NIST's randomness beacon as a source of randomness.
We also want to test out ideas to stabilise the price of the crypto-currency via a blockchain based voting system and methods of monetary base inflation/deflation.
Join the team @http://www.reddit.com/Conceptcoin/
Contact me to speak about donations/funding. Would like feedback on the Protocol below.
Protocol V0.1 Draft (as drafted by telepatheic)
Introduction
To aid interoperability, development speed and to prevent programmer confusion, ConceptCoin will be based on the existing Bitcoin protocol in v0.1, subsequent versions will implement changes to increase efficiency (such as using a faster ECDSA curve) and make the protocol more consistent. The specification is based upon https://en.bitcoin.it/wiki/Protocol_specification and v0.9.1 of the bitcoin core code. Where the two are not in agreement the v0.9.1 bitcoin core code takes priority.
There will be some small changes as follows:
The magic value is F3 B2 BA D1 The relay field is removed from the version message filterload, filteradd, filterclear, merkleblock, and alert messages are not supported 
There will be three major changes which will be explained in greater depth:
Scripting will be simplified Blocks will have a different structure to support proof of stake mining Beacon blocks are introduced 
Scripting simplifications
The only valid scripts are those of the following form:
scriptPubKey: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG scriptSig:
Blocks
Blocks are where the most significant changes are. Blocks must be signed by the block creator. To help detect double signing of blocks in future versions, the signature is of the block hash concatenated with the magic value and the timestamp. This makes sure that signing other pieces of data can't be used as evidence of signing ConceptCoin blocks.
Block header:
Version uint32_t: as in Bitcoin = 1
Timestamp uint32_t: must be greater than the last beacon block timestamp and less than the last beacon block timestamp + 60. Default is beacon block timestamp + 30
Block creator pubKey char[33]: the block creator's public key in compressed form given as where is 0x02 if y is even and 0x03 if y is odd. (see section below)
Previous block hash char[32]: the hash of the previous valid block
Merkle tree hash char[32]: As in Bitcoin
Block hash char[32]: The SHA256 hash of the previous fields
Block hash signature char[64]: The signature for the block hash concatenated with the magic value and the timestamp.
Block body:
Number of transactions uint16_t: The number of transactions which follows (note: slight difference to Bitcoin, uses fixed length integer)
Transactions starting with the coinbase transaction (same as Bitcoin)
Creating a block
Block creators are selected by the random seed in the previous beacon block. The selection is weighted by the amount of unspent output such that it becomes proof of stake based.
All pubKeyHashes from unspent outputs (except those created in the previous block) are ordered in a database by pubKeyHash from smallest to largest alongside the cumulative (starting from the smallest pubKeyHash) amount of unspent output. We take the 512 bit random seed and find the (mod total unspent output) of this number to get a random selector. The pubKeyHash selected is the one which has the smallest cumulative value next to it where the cumulative value is greater than the random selector. Here is a simplified example:
pubKeyHash Unspent output 12 30 17 4 32 5 21 12 19 9 24 16
pubKeyHash Cumulative Value of selector required 12 30 0-29 17 34 30-33 19 43 34-42 21 55 43-54 24 71 55-70 32 76 71-75
If the random output from the beacon was 412: 412 (mod 76) = 32 so pubKeyHash 17 is selected
Because not all key holders are likely to be online, blocks will not be created every minute in v0.1 (this will be modified in subsequent versions). Also in v0.1 double signing of different blocks is technically possible creating forks. Double block signing detection will be added in subsequent versions.
Beacon block
Version uint32_t: the version of the beacon block (can be used to change to different beacon specifications) = 1
Timestamp uint32_t: must match the NIST beacon timestamp
NIST version var_str: must match the NIST beacon version string
NIST frequency uint32_t: must match the NIST beacon frequency (normally 60)
NIST seed value char[64]: must match the NIST beacon seed value
NIST status uint32_t: must match the NIST beacon status code
NIST signature char[256]: must match the NIST beacon signature
NIST output value char[64]: must match the NIST beacon output value
A beacon block is a new message with command = "beacon". It allows everyone to be aware of the last random number generated without overloading the NIST randomness beacon server. The signature signs the previous output value to link the beacon blocks together.
More details will be provided on how to verify that beacon blocks are genuine.
Transaction fees
By default transaction fees are 0.
Block rewards
Block rewards are 100 base (indivisible) units. This is an arbitrary choice and there will be no economic mechanism in v0.1
The maturation period for coinbase transactions is 10 blocks but they contribute to the pubKeyHash selection algorithm in the same way as all other transactions.
Edited to update beacon block data types.
submitted by Mox16 to Bitcoin [link] [comments]

Elliptic Curve Digital Signature Algorithm Bitcoin Signature Tool for Decentralized Services Market Introduction to Bitcoin with Yours Bitcoin, Lecture 5: ECDSA Elliptic Curve Digital Signature Algorithm (ECDSA) in NS2 DE: Elliptic Curve Digital Signature Algorithm ECDSA  Teil 10 Kryptographie Crashkurs

I need to sign a hash of 256 bits with ECDSA using a private key of 256 bits, just as bitcoin does, and I am reaching desperation because of the lack of documentation of ecdsa in python. The structure of a DER encoded ECDSA signature is as follows: 30 identifies a SEQUENCE in ASN1 encoding, which is followed by the length of z (the sequence).r and scan be either 32 or 33 bytes long, depending on how big the DER encoded values are.r and s are always leaded by 02, which identify an integer value in ASN1.Finally, the tailing (ht) byte represents the hashtype The Elliptic Curve Digital Signature Algorithm (ECDSA) is a variant of DSA that uses Elliptic Curve Cryptography (ECC), a topic that we previously introduced in the post on Elliptic Curve Groups. For a given public key length, ECC bestows on ECDSA a significant security advantage over its DSA counterpart. An output that references a single Bitcoin address is a typical output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see OP_CHECKSIG). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in ... Since the length of DER encoded ECDSA signature can be 70, 71 or 72 bytes depending on the length of r and s. In other words, length of r and length of s can be either 32 bytes or 33 bytes. And they will finally sum up to exceed 64 bytes.

[index] [4230] [21676] [31501] [18248] [26595] [33165] [7550] [11207] [34371] [15257]

Elliptic Curve Digital Signature Algorithm

how to sign a bitcoin message - bitcoin signature - Duration: 8:27. blocksize Recommended for you. 8:27. ... Bitcoin ECDSA- Elliptic curve Digital Signature - Duration: 8:43. The fourth lecture covers ECDSA, or Elliptic Curve Digital Signature Algorithm, the digital signature algorithm used by bitcoin. ... Getting the ECDSA Z Value from a Bitcoin Single Input ... Elliptic Curve Digital Signature Algorithm ECDSA Part 10 Cryptography Crashcourse - Duration: 35:32. Dr. Julian Hosp - Bitcoin, Aktien, Gold und Co. 6,838 views In this video I demonstrate getting the ECDSA Z value from a bitcoin transaction containing a multi signature input. I also show the R and S values. The ECDSA R, S and Z values are used throughout ... Elliptic Curve Digital Signature Algorithm (ECDSA) in ns2: To get this project in ONLINE or through TRAINING Sessions, Contact: JP INFOTECH, Old No.31, New No.86, 1st Floor, 1st Avenue, Ashok ...

#