{"action":"created","issue":{"url":"https://api.github.com/repos/hyperledger/iroha/issues/1062","repository_url":"https://api.github.com/repos/hyperledger/iroha","labels_url":"https://api.github.com/repos/hyperledger/iroha/issues/1062/labels{/name}","comments_url":"https://api.github.com/repos/hyperledger/iroha/issues/1062/comments","events_url":"https://api.github.com/repos/hyperledger/iroha/issues/1062/events","html_url":"https://github.com/hyperledger/iroha/issues/1062","id":303998138,"number":1062,"title":"Replay attack","user":{"login":"victordrobny","id":9118241,"avatar_url":"https://avatars1.githubusercontent.com/u/9118241?v=4","gravatar_id":"","url":"https://api.github.com/users/victordrobny","html_url":"https://github.com/victordrobny","followers_url":"https://api.github.com/users/victordrobny/followers","following_url":"https://api.github.com/users/victordrobny/following{/other_user}","gists_url":"https://api.github.com/users/victordrobny/gists{/gist_id}","starred_url":"https://api.github.com/users/victordrobny/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/victordrobny/subscriptions","organizations_url":"https://api.github.com/users/victordrobny/orgs","repos_url":"https://api.github.com/users/victordrobny/repos","events_url":"https://api.github.com/users/victordrobny/events{/privacy}","received_events_url":"https://api.github.com/users/victordrobny/received_events","type":"User","site_admin":false},"labels":[{"id":808830372,"url":"https://api.github.com/repos/hyperledger/iroha/labels/discussion","name":"discussion","color":"e502ed","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":11,"created_at":"2018-03-09T22:16:29Z","updated_at":"2018-03-21T08:40:47Z","closed_at":null,"author_association":"NONE","body":"Replay attack(or double spend attack)\r\n\r\nReplay attack appears in any communicational system in general and in blockchain frameworks specifically. Most of the messages are sent through insecure channels. The first problem that appears in this situation is the identification of the author of the message. \r\n\r\nHowever even if the message is signed(and you are sure that raw message data was generated by the identified user), you need to be sure who initiates the broadcast of the message. Due to insecureness of the communicational channels in most scenarios, transmitted data can be sniffed and can be sent once more. In this case receiver will take two identical messages.\r\n\r\nFor cryptocurrencies, replay attack is one of the main issues. If transaction with transfer from A to B will be repeated by fraudster in blockchain system without double spend protection A will spend twice more money than he wanted.\r\n\r\nHere are some solutions:\r\n\r\nBitcoin(UTXO)\r\n\r\nIn bitcoin users owns a bunch of coins. Any coin couldn’t be spent partially. Each coin in bitcoin can be either be transferred to another account entirely or can be spent in order to create new coins. So if someone wants to spend some amount of bitcoins he needs to create a coin with appropriate value first. \r\n\r\nEach transaction in bitcoin has input coins and output count. Each coin in the system can be in the input and output only once. These restrictions guarantee that coin will be spent only once and all other transactions with encountered input will be treated as invalid. So the double spend attack protection is sewn in the system by design.\r\n\r\nHowever, this approach is not applicable in account-based systems. Since Iroha has only the quantity of the asset it is quite hard to rework model to use this approach.\r\n\r\nNonce\r\n\r\nAnother common approach is the nonce usage. Nonce is a number that can be used only once. It prevents transaction payload to be the same. Each time that user creates new transaction somehow takes new nonce. It leads to different hashes/signs to identical transactions. Two identical transactions with equal nonce will never be applied to the ledger.\r\n\r\nThe simplest way to generate nonce is to take a random number(string, whatever) every time. This approach is used in hyperledger sawtooth and fabric(for anonymous transactions). The disadvantage of this method is that already used nonces should be stored in order to verify the uniqueness of the new ones. To avoid storing large amounts of hashes, validity periods of transaction certificates are limited. In particular validators maintain an updated record of received transactions' hashes within the current or future validity period.\r\n\r\nAnother method that allows ensuring the uniqueness of transaction is to maintain the sequence of the nonces so the validators are able to determine whether value was used without storing it. Usually, the sequence of nonces are generated by the recurrent formula: \r\nnonce<sub>i</sub> = f(nonce<sub>i-1</sub>). It allows to not to remember all of the nonces that were used before. For example, Ethereum uses consecutive numbers in order to make nonces. Each account uses their own counter for transactions. So the first nonce for a particular user is 1, next is 2 and so on. Nonces are not unique in this scenario, however (nonce, account) is unique. It guarantees the uniqueness of the hash of the transactions.\r\n\r\nThe other common approach is to use some hash function in order to get new nonce. It is used in hyperledger fabric. The fabrics mechanism is quite complicated and depends on the type of the transaction(they use different types of certificates), but in general idea it the following: \r\nfor transactions with enrollment certificate: get first nonce (for example from genesis block), nonce<sub>next</sub> = hash(nonce<sub>prev</sub>).\r\n"},"comment":{"url":"https://api.github.com/repos/hyperledger/iroha/issues/comments/374866047","html_url":"https://github.com/hyperledger/iroha/issues/1062#issuecomment-374866047","issue_url":"https://api.github.com/repos/hyperledger/iroha/issues/1062","id":374866047,"user":{"login":"l4l","id":5658339,"avatar_url":"https://avatars2.githubusercontent.com/u/5658339?v=4","gravatar_id":"","url":"https://api.github.com/users/l4l","html_url":"https://github.com/l4l","followers_url":"https://api.github.com/users/l4l/followers","following_url":"https://api.github.com/users/l4l/following{/other_user}","gists_url":"https://api.github.com/users/l4l/gists{/gist_id}","starred_url":"https://api.github.com/users/l4l/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/l4l/subscriptions","organizations_url":"https://api.github.com/users/l4l/orgs","repos_url":"https://api.github.com/users/l4l/repos","events_url":"https://api.github.com/users/l4l/events{/privacy}","received_events_url":"https://api.github.com/users/l4l/received_events","type":"User","site_admin":false},"created_at":"2018-03-21T08:40:47Z","updated_at":"2018-03-21T08:40:47Z","author_association":"MEMBER","body":"@victordrobny actually both cases are applicable to mst\r\nIt consider new signature on the tx iff hashes are equals. That implies that the second signatory must now in advance stuff like time/nonce and sign exactly same tx.\r\nMST component actually send **only 1** tx with necessary signatures (and to the tx processor, not ordering service)\r\n\r\n@neewy It might be issues with timestamp synchronization. So it basically become similar to the nonces: you need to ask it, to make sure that tx doesn't go to nowhere. And as long as clock as physically different you need to do it regularly "}}
{"actor":{"display_login":"l4l"}}