Tight Proofs of Space and Replication
Total Page:16
File Type:pdf, Size:1020Kb

Load more
Recommended publications
-
Computationally Data-Independent Memory Hard Functions
Computationally Data-Independent Memory Hard Functions Mohammad Hassan Ameri∗ Jeremiah Blocki† Samson Zhou‡ November 18, 2019 Abstract Memory hard functions (MHFs) are an important cryptographic primitive that are used to design egalitarian proofs of work and in the construction of moderately expensive key-derivation functions resistant to brute-force attacks. Broadly speaking, MHFs can be divided into two categories: data-dependent memory hard functions (dMHFs) and data-independent memory hard functions (iMHFs). iMHFs are resistant to certain side-channel attacks as the memory access pattern induced by the honest evaluation algorithm is independent of the potentially sensitive input e.g., password. While dMHFs are potentially vulnerable to side-channel attacks (the induced memory access pattern might leak useful information to a brute-force attacker), they can achieve higher cumulative memory complexity (CMC) in comparison than an iMHF. In particular, any iMHF that can be evaluated in N steps on a sequential machine has CMC at 2 most N log log N . By contrast, the dMHF scrypt achieves maximal CMC Ω(N 2) — though O log N the CMC of scrypt would be reduced to just (N) after a side-channel attack. In this paper, we introduce the notion ofO computationally data-independent memory hard functions (ciMHFs). Intuitively, we require that memory access pattern induced by the (ran- domized) ciMHF evaluation algorithm appears to be independent from the standpoint of a computationally bounded eavesdropping attacker — even if the attacker selects the initial in- put. We then ask whether it is possible to circumvent known upper bound for iMHFs and build a ciMHF with CMC Ω(N 2). -
Lab 5: Bittorrent Client Implementation
Lab 5: BitTorrent Client Implementation Due: Nov. 30th at 11:59 PM Milestone: Nov. 19th during Lab Overview In this lab, you and your lab parterner will develop a basic BitTorrent client that can, at minimal, exchange a file between multiple peers, and at best, function as a full feature BitTorrent Client. The programming in this assignment will be in C requiring standard sockets, and thus you will not need to have root access. You should be able to develop your code on any CS lab machine or your personal machine, but all code will be tested on the CS lab. Deliverable Your submission should minimally include the following programs and files: • REDME • Makefile • bencode.c|h • bt lib.c|h • bt setup.c|h • bt client • client trace.[n].log • sample torrent.torrent Your README file should contain a short header containing your name, username, and the assignment title. The README should additionally contain a short description of your code, tasks accomplished, and how to compile, execute, and interpret the output of your programs. Your README should also contain a list of all submitted files and code and the functionality implemented in different code files. This is a large assignment, and this will greatly aid in grading. As always, if there are any short answer questions in this lab write-up, you should provide well marked answers in the README, as well as indicate that you’ve completed any of the extra credit (so that I don’t forget to grade it). Milestones The entire assignment will be submitted and graded, but your group will also hold a milestone meeting to receive feedback on your current implementation. -
A Decentralized Cloud Storage Network Framework
Storj: A Decentralized Cloud Storage Network Framework Storj Labs, Inc. October 30, 2018 v3.0 https://github.com/storj/whitepaper 2 Copyright © 2018 Storj Labs, Inc. and Subsidiaries This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 license (CC BY-SA 3.0). All product names, logos, and brands used or cited in this document are property of their respective own- ers. All company, product, and service names used herein are for identification purposes only. Use of these names, logos, and brands does not imply endorsement. Contents 0.1 Abstract 6 0.2 Contributors 6 1 Introduction ...................................................7 2 Storj design constraints .......................................9 2.1 Security and privacy 9 2.2 Decentralization 9 2.3 Marketplace and economics 10 2.4 Amazon S3 compatibility 12 2.5 Durability, device failure, and churn 12 2.6 Latency 13 2.7 Bandwidth 14 2.8 Object size 15 2.9 Byzantine fault tolerance 15 2.10 Coordination avoidance 16 3 Framework ................................................... 18 3.1 Framework overview 18 3.2 Storage nodes 19 3.3 Peer-to-peer communication and discovery 19 3.4 Redundancy 19 3.5 Metadata 23 3.6 Encryption 24 3.7 Audits and reputation 25 3.8 Data repair 25 3.9 Payments 26 4 4 Concrete implementation .................................... 27 4.1 Definitions 27 4.2 Peer classes 30 4.3 Storage node 31 4.4 Node identity 32 4.5 Peer-to-peer communication 33 4.6 Node discovery 33 4.7 Redundancy 35 4.8 Structured file storage 36 4.9 Metadata 39 4.10 Satellite 41 4.11 Encryption 42 4.12 Authorization 43 4.13 Audits 44 4.14 Data repair 45 4.15 Storage node reputation 47 4.16 Payments 49 4.17 Bandwidth allocation 50 4.18 Satellite reputation 53 4.19 Garbage collection 53 4.20 Uplink 54 4.21 Quality control and branding 55 5 Walkthroughs ............................................... -
Características Y Aplicaciones De Las Funciones Resumen Criptográficas En La Gestión De Contraseñas
Características y aplicaciones de las funciones resumen criptográficas en la gestión de contraseñas Alicia Lorena Andrade Bazurto Instituto Universitario de Investigación en Informática Escuela Politécnica Superior Características y aplicaciones de las funciones resumen criptográficas en la gestión de contraseñas ALICIA LORENA ANDRADE BAZURTO Tesis presentada para aspirar al grado de DOCTORA POR LA UNIVERSIDAD DE ALICANTE DOCTORADO EN INFORMÁTICA Dirigida por: Dr. Rafael I. Álvarez Sánchez Alicante, julio 2019 Índice Índice de tablas .................................................................................................................. vii Índice de figuras ................................................................................................................. ix Agradecimiento .................................................................................................................. xi Resumen .......................................................................................................................... xiii Resum ............................................................................................................................... xv Abstract ........................................................................................................................... xvii 1 Introducción .................................................................................................................. 1 1.1 Objetivos ...............................................................................................................4 -
Argon2: the Memory-Hard Function for Password Hashing and Other Applications
Argon2: the memory-hard function for password hashing and other applications Designers: Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich University of Luxembourg, Luxembourg [email protected], [email protected], [email protected] https://www.cryptolux.org/index.php/Argon2 https://github.com/P-H-C/phc-winner-argon2 https://github.com/khovratovich/Argon2 Version 1.3 of Argon2: PHC release February 29, 2016 Contents 1 Introduction 2 2 Definitions 3 2.1 Motivation . 3 2.2 Model for memory-hard functions . 4 3 Specification of Argon2 4 3.1 Inputs . 4 3.2 Operation . 5 3.3 Indexing . 6 3.4 Compression function G ......................................... 7 4 Features 8 4.1 Available features . 8 4.2 Possible future extensions . 9 5 Security analysis 9 5.1 Ranking tradeoff attack . 9 5.2 Memory optimization attack . 9 5.3 Attack on iterative compression function . 10 5.4 Security of Argon2 to generic attacks . 10 5.5 Security of Argon2 to ranking tradeoff attacks . 11 5.6 Security of Argon2i to generic tradeoff attacks on random graphs . 12 5.7 Summary of tradeoff attacks . 12 6 Design rationale 12 6.1 Indexing function . 12 6.2 Implementing parallelism . 13 6.3 Compression function design . 15 6.3.1 Overview . 15 6.3.2 Design criteria . 15 6.4 User-controlled parameters . 15 7 Performance 16 7.1 x86 architecture . 16 8 Applications 16 1 9 Recommended parameters 17 10 Conclusion 17 A Permutation 18 P B Additional functionality 19 C Change log 19 C.1 v.1.3 . 19 C.2 v1.2.1 { February 1st, 2016 . -
Sok: Tools for Game Theoretic Models of Security for Cryptocurrencies
SoK: Tools for Game Theoretic Models of Security for Cryptocurrencies Sarah Azouvi Alexander Hicks Protocol Labs University College London University College London Abstract form of mining rewards, suggesting that they could be prop- erly aligned and avoid traditional failures. Unfortunately, Cryptocurrencies have garnered much attention in recent many attacks related to incentives have nonetheless been years, both from the academic community and industry. One found for many cryptocurrencies [45, 46, 103], due to the interesting aspect of cryptocurrencies is their explicit consid- use of lacking models. While many papers aim to consider eration of incentives at the protocol level, which has motivated both standard security and game theoretic guarantees, the vast a large body of work, yet many open problems still exist and majority end up considering them separately despite their current systems rarely deal with incentive related problems relation in practice. well. This issue arises due to the gap between Cryptography Here, we consider the ways in which models in Cryptog- and Distributed Systems security, which deals with traditional raphy and Distributed Systems (DS) can explicitly consider security problems that ignore the explicit consideration of in- game theoretic properties and incorporated into a system, centives, and Game Theory, which deals best with situations looking at requirements based on existing cryptocurrencies. involving incentives. With this work, we offer a systemati- zation of the work that relates to this problem, considering papers that blend Game Theory with Cryptography or Dis- Methodology tributed systems. This gives an overview of the available tools, and we look at their (potential) use in practice, in the context As we are covering a topic that incorporates many different of existing blockchain based systems that have been proposed fields coming up with an extensive list of papers would have or implemented. -
Blockchain and The
NOTES ACKNOWLEDGMENTS INDEX Notes Introduction 1. The manifesto dates back to 1988. See Timothy May, “The Crypto Anarchist Manifesto” (1992), https:// www . activism . net / cypherpunk / crypto - anarchy . html. 2. Ibid. 3. Ibid. 4. Ibid. 5. Ibid. 6. Timothy May, “Crypto Anarchy and Virtual Communities” (1994), http:// groups . csail . mit . edu / mac / classes / 6 . 805 / articles / crypto / cypherpunks / may - virtual - comm . html. 7. Ibid. 8. For example, as we wi ll describe in more detail in Chapter 1, the Bitcoin blockchain is currently stored on over 6,000 computers in eighty- nine jurisdictions. See “Global Bitcoin Node Distribution,” Bitnodes, 21 . co, https:// bitnodes . 21 . co / . Another large blockchain- based network, Ethereum, has over 12,000 nodes, also scattered across the globe. See Ethernodes, https:// www . ethernodes . org / network / 1. 9. See note 8. 10. Some blockchains are not publicly accessible (for more on this, see Chapter 1). These blockchains are referred to as “private blockchains” and are not the focus of this book. 11. See Chapter 1. 12. The Eu ro pean Securities and Market Authority, “Discussion Paper: The Dis- tributed Ledger Technology Applied to Securities Markets,” ESMA / 2016 / 773, June 2, 2016: at 17, https:// www . esma . europa . eu / sites / default / files / library / 2016 - 773 _ dp _ dlt . pdf. 213 214 NOTES TO PAGES 5–13 13. The phenomena of order without law also has been described in other con- texts, most notably by Robert Ellickson in his seminal work Order without Law (Cambridge, MA: Harvard University Press, 1994). 14. Joel Reidenberg has used the term “lex informatica” to describe rules imple- mented by centralized operators online. -
Proofs of Replication Are Also Relevant in the Private-Verifier Setting of Proofs of Data Replication
PoReps: Proofs of Space on Useful Data Ben Fisch Stanford University, Protocol Labs Abstract A proof-of-replication (PoRep) is an interactive proof system in which a prover defends a publicly verifiable claim that it is dedicating unique resources to storing one or more retrievable replicas of a data file. In this sense a PoRep is both a proof of space (PoS) and a proof of retrievability (PoR). This paper establishes a foundation for PoReps, exploring both their capabilities and their limitations. While PoReps may unconditionally demonstrate possession of data, they fundamentally cannot guarantee that the data is stored redundantly. Furthermore, as PoReps are proofs of space, they must rely either on rational time/space tradeoffs or timing bounds on the online prover's runtime. We introduce a rational security notion for PoReps called -rational replication based on the notion of an -Nash equilibrium, which captures the property that a server does not gain any significant advantage by storing its data in any other (non-redundant) format. We apply our definitions to formally analyze two recently proposed PoRep constructions based on verifiable delay functions and depth robust graphs. Lastly, we reflect on a notable application of PoReps|its unique suitability as a Nakamoto consensus mechanism that replaces proof-of-work with PoReps on real data, simultaneously incentivizing and subsidizing the cost of file storage. 1 Introduction A proof-of-replication (PoRep) builds on the two prior concepts of proofs-of-retrievability (PoR) [30] and proofs-of-space (PoS) [24]. In the former a prover demonstrates that it can retrieve a file and in the latter the prover demonstrates that it is using some minimum amount of space to store information. -
Performance Analysis of Cryptographic Hash Functions Suitable for Use in Blockchain
I. J. Computer Network and Information Security, 2021, 2, 1-15 Published Online April 2021 in MECS (http://www.mecs-press.org/) DOI: 10.5815/ijcnis.2021.02.01 Performance Analysis of Cryptographic Hash Functions Suitable for Use in Blockchain Alexandr Kuznetsov1 , Inna Oleshko2, Vladyslav Tymchenko3, Konstantin Lisitsky4, Mariia Rodinko5 and Andrii Kolhatin6 1,3,4,5,6 V. N. Karazin Kharkiv National University, Svobody sq., 4, Kharkiv, 61022, Ukraine E-mail: [email protected], [email protected], [email protected], [email protected], [email protected] 2 Kharkiv National University of Radio Electronics, Nauky Ave. 14, Kharkiv, 61166, Ukraine E-mail: [email protected] Received: 30 June 2020; Accepted: 21 October 2020; Published: 08 April 2021 Abstract: A blockchain, or in other words a chain of transaction blocks, is a distributed database that maintains an ordered chain of blocks that reliably connect the information contained in them. Copies of chain blocks are usually stored on multiple computers and synchronized in accordance with the rules of building a chain of blocks, which provides secure and change-resistant storage of information. To build linked lists of blocks hashing is used. Hashing is a special cryptographic primitive that provides one-way, resistance to collisions and search for prototypes computation of hash value (hash or message digest). In this paper a comparative analysis of the performance of hashing algorithms that can be used in modern decentralized blockchain networks are conducted. Specifically, the hash performance on different desktop systems, the number of cycles per byte (Cycles/byte), the amount of hashed message per second (MB/s) and the hash rate (KHash/s) are investigated. -
Questions for Crypto Currencies
www.YoYoBrain.com - Accelerators for Memory and Learning Questions for Crypto Currencies Category: Default - (170 questions) Cryptocurrencies: vwap volume weighted average price Blockchain: multisig using multiple key signatures to approve a transaction Blockchain: demurrage a charge payable to the owner of a chartered ship in respect of failure to load or discharge the ship within the time agreed Blockchain: coin mixing pooling your coins with other transactions so they are more anonymous, using services like Dark Coin, Dark Wallet and BitMixer Blockchain: attestation provide or serve as clear evidence of Blockchain: smart property property whose ownership is controlled via the blockchain, using contracts subject to existing law Blockchain: Ethereum Swarm decentralized file serving method Blockchain: Ethereum Whisper peer-to-peer protocol for secret messaging and digital cryptography used to refer to using the blockchain to Blockchain: digital art register any form of IP Blockchain: Zookos's Triangle Problem encountered in any system that gives names to participants in a network protocol: how to make identities such as a URL or user handle simultaneously secure, decentralized and human-usable Blockchain: futarchy a 2 level process by which individuals first vote on general specified outcomes (like "increase GDP") and secondly, vote on specific proposals for achieving those outcomes Blockchain: cryptocurrency demurrage being deflationary (value losing) over time Blockchain: hashing functions create a maps data of any size to a bit string -
HODL Deck V4
BUILDING THE WORLD’S LEADING PRIVACY INVESTMENT VEHICLE Presentation Subtitle 2020 Cypherpunk Holdings Inc. CSE: HODL INVESTOR PRESENTATION January 2021 1 Investor Presentation January 2021 DISCLAIMER - CAUTIONARY NOTE REGARDING FORWARD-LOOKING INFORMATION This presentation contains “forward-looking information” within the meaning of applicable securities laws. Generally, any statements that are not historical facts may contain forward-looking information, and forward-looking information can be identified by the use of forward-looking terminology such as “plans”, “expects” or “does not expect”, “is expected”, “budget”, “scheduled”, “estimates”, “forecasts”, “intends”, “anticipates” or “does not anticipate”, or “believes”, or variations of such words and phrases or indicates that certain actions, events or results “may”, “could”, “would”, “might” or “will be” taken, “occur” or “be achieved”. Forward-looking information includes, but is not limited to the Company’s goal of making investments in, crypto-currencies, digital currencies and assets, the blockchain, software and other sectors, financial information and enhancing value. There is no assurance that the Company’s plans or objectives will be implemented as set out herein, or at all. Forward-looking information is based on certain factors and assumptions the Company believes to be reasonable at the time such statements are made and is subject to known and unknown risks, uncertainties and other factors that may cause the actual results, level of activity, performance or achievements of the Company to be materially different from those expressed or implied by such forward-looking information. There can be no assurance that such forward-looking information will prove to be accurate, as actual results and future events could differ materially from those anticipated in such information. -
Just in Time Hashing
Just in Time Hashing Benjamin Harsha Jeremiah Blocki Purdue University Purdue University West Lafayette, Indiana West Lafayette, Indiana Email: [email protected] Email: [email protected] Abstract—In the past few years billions of user passwords prove and as many users continue to select low-entropy have been exposed to the threat of offline cracking attempts. passwords, finding it too difficult to memorize multiple Such brute-force cracking attempts are increasingly dangerous strong passwords for each of their accounts. Key stretching as password cracking hardware continues to improve and as serves as a last line of defense for users after a password users continue to select low entropy passwords. Key-stretching breach. The basic idea is to increase guessing costs for the techniques such as hash iteration and memory hard functions attacker by performing hash iteration (e.g., BCRYPT[75] can help to mitigate the risk, but increased key-stretching effort or PBKDF2 [59]) or by intentionally using a password necessarily increases authentication delay so this defense is hash function that is memory hard (e.g., SCRYPT [74, 74], fundamentally constrained by usability concerns. We intro- Argon2 [12]). duce Just in Time Hashing (JIT), a client side key-stretching Unfortunately, there is an inherent security/usability algorithm to protect user passwords against offline brute-force trade-off when adopting traditional key-stretching algo- cracking attempts without increasing delay for the user. The rithms such as PBKDF2, SCRYPT or Argon2. If the key- basic idea is to exploit idle time while the user is typing in stretching algorithm cannot be computed quickly then we their password to perform extra key-stretching.