Added: incubator/milagro/site/www/docs/milagro-crypto/index.html URL: http://svn.apache.org/viewvc/incubator/milagro/site/www/docs/milagro-crypto/index.html?rev=1860997&view=auto ============================================================================== --- incubator/milagro/site/www/docs/milagro-crypto/index.html (added) +++ incubator/milagro/site/www/docs/milagro-crypto/index.html Tue Jun 11 00:28:48 2019 @@ -0,0 +1,128 @@ +<!DOCTYPE html><html lang="en"><head><meta charSet="utf-8"/><meta http-equiv="X-UA-Compatible" content="IE=edge"/><title>Milagro Crypto · Apache Milagro</title><meta name="viewport" content="width=device-width"/><meta name="generator" content="Docusaurus"/><meta name="description" content="<p>One of the critical points about information security is to give access to resources only to authorized entities and deny access to unauthorized ones.</p> +"/><meta name="docsearch:language" content="en"/><meta property="og:title" content="Milagro Crypto · Apache Milagro"/><meta property="og:type" content="website"/><meta property="og:url" content="https://milagro.apache.org/"/><meta property="og:description" content="<p>One of the critical points about information security is to give access to resources only to authorized entities and deny access to unauthorized ones.</p> +"/><meta name="twitter:card" content="summary"/><link rel="shortcut icon" href="/img/favicon.ico"/><link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/default.min.css"/><link rel="alternate" type="application/atom+xml" href="https://milagro.apache.org/blog/atom.xml"; title="Apache Milagro Blog ATOM Feed"/><link rel="alternate" type="application/rss+xml" href="https://milagro.apache.org/blog/feed.xml"; title="Apache Milagro Blog RSS Feed"/><script type="text/javascript" src="https://buttons.github.io/buttons.js";></script><script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.5/MathJax.js?config=TeX-MML-AM_CHTML";></script><script src="/js/scrollSpy.js"></script><link rel="stylesheet" href="/css/main.css"/><script src="/js/codetabs.js"></script></head><body class="sideNavVisible separateOnPageNav"><div class="fixedHeaderContainer"><div class="headerWrapper wrapper"><header><a href="/"><img class="logo" src="/img/milagro .svg" alt="Apache Milagro"/><h2 class="headerTitleWithLogo">Apache Milagro</h2></a><div class="navigationWrapper navigationSlider"><nav class="slidingNav"><ul class="nav-site nav-site-internal"><li class="siteNavGroupActive"><a href="/docs/milagro-intro" target="_self">Docs</a></li><li class=""><a href="/help" target="_self">Support</a></li><li class="siteNavGroupActive"><a href="/docs/contributor-guide" target="_self">Contributing</a></li><li class=""><a href="/blog/" target="_self">Status</a></li></ul></nav></div></header></div></div><div class="navPusher"><div class="docMainWrapper wrapper"><div class="container docsNavContainer" id="docsNav"><nav class="toc"><div class="toggleNav"><section class="navWrapper wrapper"><div class="navBreadcrumb wrapper"><div class="navToggle" id="navToggler"><div class="hamburger-menu"><div class="line1"></div><div class="line2"></div><div class="line3"></div></div></div><h2><i>âº</i><span>About Milagro</span></h2><div class="tocToggler" id="to cToggler"><i class="icon-toc"></i></div></div><div class="navGroups"><div class="navGroup"><h3 class="navGroupCategoryTitle">About Milagro</h3><ul class=""><li class="navListItem"><a class="navItem" href="/docs/milagro-intro">Milagro Introduction</a></li><li class="navListItem navListItemActive"><a class="navItem" href="/docs/milagro-crypto">Milagro Crypto</a></li><li class="navListItem"><a class="navItem" href="/docs/milagro-protocols">Milagro Protocols</a></li><li class="navListItem"><a class="navItem" href="/docs/milagro-design">Milagro Design</a></li></ul></div><div class="navGroup"><h3 class="navGroupCategoryTitle">AMCL Library</h3><ul class=""><li class="navListItem"><a class="navItem" href="/docs/amcl-overview">AMCL Overview</a></li><li class="navListItem"><a class="navItem" href="/docs/amcl-c-api">AMCL C API</a></li><li class="navListItem"><a class="navItem" href="/docs/amcl-javascript-api">AMCL JavaScript API</a></li></ul></div><div class="navGroup"><h3 class="navGroupCateg oryTitle">D-TA Node</h3><ul class=""><li class="navListItem"><a class="navItem" href="/docs/d-ta-overview">D-TA Node Overview</a></li><li class="navListItem"><a class="navItem" href="/docs/d-ta-api">D-TA Node API</a></li></ul></div><div class="navGroup"><h3 class="navGroupCategoryTitle">ZKP-MFA Clients/Servers</h3><ul class=""><li class="navListItem"><a class="navItem" href="/docs/zkp-mfa-overview">ZKP-MFA Overview</a></li><li class="navListItem"><a class="navItem" href="/docs/zkp-mfa-api">ZKP-MFA API</a></li></ul></div><div class="navGroup"><h3 class="navGroupCategoryTitle">Project Info</h3><ul class=""><li class="navListItem"><a class="navItem" href="/docs/contributor-guide">Contributor's Guide</a></li></ul></div></div></section></div><script> + var coll = document.getElementsByClassName('collapsible'); + var checkActiveCategory = true; + for (var i = 0; i < coll.length; i++) { + var links = coll[i].nextElementSibling.getElementsByTagName('*'); + if (checkActiveCategory){ + for (var j = 0; j < links.length; j++) { + if (links[j].classList.contains('navListItemActive')){ + coll[i].nextElementSibling.classList.toggle('hide'); + coll[i].childNodes[1].classList.toggle('rotate'); + checkActiveCategory = false; + break; + } + } + } + + coll[i].addEventListener('click', function() { + var arrow = this.childNodes[1]; + arrow.classList.toggle('rotate'); + var content = this.nextElementSibling; + content.classList.toggle('hide'); + }); + } + + document.addEventListener('DOMContentLoaded', function() { + createToggler('#navToggler', '#docsNav', 'docsSliderActive'); + createToggler('#tocToggler', 'body', 'tocActive'); + + var headings = document.querySelector('.toc-headings'); + headings && headings.addEventListener('click', function(event) { + var el = event.target; + while(el !== headings){ + if (el.tagName === 'A') { + document.body.classList.remove('tocActive'); + break; + } else{ + el = el.parentNode; + } + } + }, false); + + function createToggler(togglerSelector, targetSelector, className) { + var toggler = document.querySelector(togglerSelector); + var target = document.querySelector(targetSelector); + + if (!toggler) { + return; + } + + toggler.onclick = function(event) { + event.preventDefault(); + + target.classList.toggle(className); + }; + } + }); + </script></nav></div><div class="container mainContainer"><div class="wrapper"><div class="post"><header class="postHeader"><h1 class="postHeaderTitle">Milagro Crypto</h1></header><article><div><span><p>One of the critical points about information security is to give access to resources only to authorized entities and deny access to unauthorized ones. +Preventing unauthorized access very often comes down to making it <strong><em>almost impossible</em></strong>, i.e., tough, expensive, complicated, and time-consuming for the unauthorized entities to get access to resources.</p> +<p>The same principles apply to cryptography. In most cases, a suitable encryption mechanism satisfies at least two basic requirements:</p> +<ol> +<li>It is possible to give easy access to encrypted, cryptographically protected content to authorized entities.</li> +<li>It is possible to make it extremely challenging for unauthorized entities to access encrypted (ditto) content.</li> +</ol> +<p>Using the above, we can define an operation: Encryption that is tough to reverse without possessing a particular parameter, for example, a decryption key. +In RSA-based encryption two prime numbers, the private key, are multiplied to generate a public key, so that it is almost impossible to reverse the operation and retrieve the original prime numbers.</p> +<p>Multiple sources are available online to read more on the topic. We recommend this short paper from <a href="https://math.berkeley.edu/~kpmann/encryption.pdf";>Cal Berkeley at this link</a>.</p> +<p>As noted in the mentioned paper, with RSA, we need enormous prime numbers to make it <strong><em>almost impossible</em></strong> to break the encryption, hence to find the two big prime numbers. +On elliptic curves, multiplication of a point by a number can be defined so that much shorter numbers than in the big prime number case are needed to reach the same level of <strong><em>almost impossibility</em></strong>.</p> +<h2><a class="anchor" aria-hidden="true" id="elliptic-curve-cryptography"></a><a href="#elliptic-curve-cryptography" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Elliptic Curve Cryptography</h2> +<p>Elliptic curves are another way to do encryption. Elliptic curves are mathematical structures, on which operations like addition and multiplications of points are easily defined. +In particular, multiplication of a point by a number is a relatively easy operation to compute, while it is <strong><em>almost impossible</em></strong> to reverse the process, that is, to determine +the multiplier knowing the result of the multiplication.</p> +<p>The problem of reversing the multiplication is known as the Discrete Logarithm Problem on elliptic curves (ECDLP). +The difference in computational complexity (between performing the multiplication and reversing the result to retrieve the multiplier) is one of the essential cornerstones of elliptic curve cryptography.</p> +<h2><a class="anchor" aria-hidden="true" id="pairing-based-cryptography"></a><a href="#pairing-based-cryptography" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Pairing Based Cryptography</h2> +<p>Using elliptic curves we can now define on some elliptic curve a bilinear function called a <strong><em>pairing</em></strong>, which enables a mapping from two points on the same curve (or points on two related curves) into a different mathematical structure called a finite field. The bilinearity of the pairing is the key characteristic that makes pairing interesting and widely used in cryptography.</p> +<p>A <strong><em>bilinear pairing</em></strong> \( e \) maps a pair of points (hence the name pairing) on an elliptic curve \( E \), defined over some field \( F_{q} \) to an element of the multiplicative group of a finite extension of \( {F}_{q^k} \).</p> +<p>$$ e(mA+B, nP + Q) = e(A,P)^{mn} e(B, Q) $$</p> +<p>The elements \( P \) and \( Q \) lie in two different groups, respectively \( G_{1} \) and \( G_{2} \). The choice of those two different group determines a different <strong><em>types</em></strong> of pairing.</p> +<p>Let \( E \) an ordinary elliptic curve, take \( G_{1} \neq G_{2} \), and if there is not an efficiently computable isomorphism \( \phi:G_{1}\to G_{2} \) then the pairing is said to be of <strong><em>Type\( -3 \)</em></strong>.</p> +<p>Currently, most of the state-of-the-art implementations of pairings take place on ordinary curves that assume the <strong><em>Type\( -3 \)</em></strong> scenario for reasons of efficiency and secure implementation.</p> +<h2><a class="anchor" aria-hidden="true" id="identity-based-encryption"></a><a href="#identity-based-encryption" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Identity Based Encryption</h2> +<p>Pairing-based cryptography builds on elliptic curve-based cryptography, but the extra functionality of the pairing enables us to design schemes which would otherwise be impossible to realize, or would be prohibitively expensive to do using RSA-based cryptosystems.</p> +<p>Identity-based encryption (IBE) is one such scheme that has received a large of amount of attention from the crypto community, and where commercially available products have been on the market for some time and are in wide use today.</p> +<p>IBE is similar to classical asymmetric key cryptography, in that each user has a public key for encryption and a private key for decryption. But there are many differences:</p> +<ol> +<li>IBE allows public keys to be set to the value of a pre-existing identifier, such as an email address, while in PKI the public key does not contain the notion of an identity, and the association with an identifier is created by a certificate signed by a third party (Certification Authority).</li> +<li>Clients or individual users do not generate private keys, but must instead download them from a trusted third party known as the Trust Authority (TA).</li> +<li>In IBE, to encrypt messages, the sender must obtain public âsystem parametersâ from the Trust Authority (TA). These system parameters are used in combination with the intended recipientâs identity string (e.g. email address) to generate an encrypted message.</li> +</ol> +<h2><a class="anchor" aria-hidden="true" id="post-quantum-cryptography"></a><a href="#post-quantum-cryptography" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Post-Quantum Cryptography</h2> +<p>"Post-quantum cryptography (sometimes referred to as quantum-proof, quantum-safe or quantum-resistant) refers to cryptographic algorithms (usually public-key algorithms) that are thought to be secure against an attack by a quantum computer. As of 2018, this is not true for the most popular public-key algorithms, which can be efficiently broken by a sufficiently strong hypothetical quantum computer.</p> +<p>The problem with currently popular algorithms is that their security relies on one of three hard mathematical problems: the integer factorization problem, the discrete logarithm problem or the elliptic-curve discrete logarithm problem. All of these problems can be easily solved on a sufficiently powerful quantum computer running Shor's algorithm.</p> +<p>Even though current, publicly known, experimental quantum computers lack processing power to break any real cryptographic algorithm, many cryptographers are designing new algorithms to prepare for a time when quantum computing becomes a threat."<sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup></p> +<h2><a class="anchor" aria-hidden="true" id="zero-knowledge-proof"></a><a href="#zero-knowledge-proof" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Zero Knowledge Proof</h2> +<p>"In cryptography, a <strong>zero-knowledge proof</strong> or <strong>zero-knowledge protocol</strong> is a method by which one party (the <em>prover</em>) can prove to another party (the <em>verifier</em>) that a given statement is true, without conveying any information apart from the fact that the statement is indeed true.</p> +<p>If proving the statement requires knowledge of some secret information on the part of the prover, the definition implies that the verifier will not be able to prove the statement in turn to anyone else, since the verifier does not possess the secret information.</p> +<p>Notice that the statement being proved must include the assertion that the prover has such knowledge (otherwise, the statement would not be proved in zero-knowledge, since at the end of the protocol the verifier would gain the additional information that the prover has knowledge of the required secret information).</p> +<p>If the statement consists <em>only</em> of the fact that the prover possesses the secret information, it is a special case known as <em>zero-knowledge proof of knowledge</em>, and it nicely illustrates the essence of the notion of zero-knowledge proofs: proving that one has knowledge of certain information is trivial if one is allowed to simply reveal that information; the challenge is proving that one has such knowledge without revealing the secret information or anything else."<sup class="footnote-ref"><a href="#fn2" id="fnref2">[2]</a></sup></p> +<h2><a class="anchor" aria-hidden="true" id="summary"></a><a href="#summary" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Summary</h2> +<p><strong>Elliptic curve cryptography</strong> is an attractive alternative to conventional public key cryptography for implementation on constrained devices, where the significant computational resources i.e. speed, memory are limited and low-power wireless communication protocols is essential. It attains the same security levels as traditional cryptosystems using smaller parameter sizes.</p> +<p><strong>Pairing-based cryptography</strong> builds on elliptic curve-based cryptography, but the extra functionality of the pairing enables us to design schemes which would otherwise be impossible to realize, or would be prohibitively expensive. Examples include identity-based encryption, group signatures and non-interactive zero-knowledge proofs.</p> +<p><strong>Identity-based encryption</strong> doesnât require certificates and certificate authorities. A trusted third party generates all the private keys, but all the public keys can be derived knowing the identity of the public key owner, for example, an email address. That means that no certificate is needed to bind a public key to its owner. Typically, it is up to the application to verify the owner possesses access to the unique identity attribute during the enrollment process in which a client obtains a private key.</p> +<p><strong>Post-quantum cryptography</strong> Post-quantum cryptography are cryptosystems which can be run on a classical computer, but are secure even if an adversary possesses a quantum computer. For data that must be private, but has the potential to be long lived and publicly available, using post-quantum secure algorithms like AES 256-bit for encryption and SIKE for encapsulation of encryption keys is essential.</p> +<p><strong>Zero-knowledge proof</strong> is a method by which one party (the prover) can prove to another party (the verifier) that a given statement is true, without conveying any information apart from the fact that the statement is indeed true.</p> +<p>For an in-depth dive into the cryptographic protocols in use within the Milagro framework, see the next section <a href="milagro-protocols.html">Milagro Protocols</a>.</p> +<hr> + + <div class="admonition admonition-note"> + <div class="admonition-heading"> + <h5><div class="admonition-icon"><svg xmlns="http://www.w3.org/2000/svg"; width="14" height="16" viewBox="0 0 14 16"><path fill-rule="evenodd" d="M6.3 5.69a.942.942 0 0 1-.28-.7c0-.28.09-.52.28-.7.19-.18.42-.28.7-.28.28 0 .52.09.7.28.18.19.28.42.28.7 0 .28-.09.52-.28.7a1 1 0 0 1-.7.3c-.28 0-.52-.11-.7-.3zM8 7.99c-.02-.25-.11-.48-.31-.69-.2-.19-.42-.3-.69-.31H6c-.27.02-.48.13-.69.31-.2.2-.3.44-.31.69h1v3c.02.27.11.5.31.69.2.2.42.31.69.31h1c.27 0 .48-.11.69-.31.2-.19.3-.42.31-.69H8V7.98v.01zM7 2.3c-3.14 0-5.7 2.54-5.7 5.68 0 3.14 2.56 5.7 5.7 5.7s5.7-2.55 5.7-5.7c0-3.15-2.56-5.69-5.7-5.69v.01zM7 .98c3.86 0 7 3.14 7 7s-3.14 7-7 7-7-3.12-7-7 3.14-7 7-7z"/></svg></div> See an error in this documentation?</h5> + </div> + <div class="admonition-content"> + <p>Submit a pull request on the development branch of <a href="https://github.com/apache/incubator-milagro";>Milagro Website Repo</a>.</p> +</div></div><!-- +Supported admonition types are: caution, note, important, tip, warning. +--><hr class="footnotes-sep"> +<section class="footnotes"> +<ol class="footnotes-list"> +<li id="fn1" class="footnote-item"><p><a href="https://en.wikipedia.org/wiki/Post-quantum_cryptography";>Wikipedia article</a> <a href="#fnref1" class="footnote-backref">â©</a></p> +</li> +<li id="fn2" class="footnote-item"><p><a href="https://en.wikipedia.org/wiki/Zero-knowledge_proof";>Wikipedia article</a> <a href="#fnref2" class="footnote-backref">â©</a></p> +</li> +</ol> +</section> +</span></div></article></div><div class="docs-prevnext"><a class="docs-prev button" href="/docs/milagro-intro"><span class="arrow-prev">â </span><span>Milagro Introduction</span></a><a class="docs-next button" href="/docs/milagro-protocols"><span>Milagro Protocols</span><span class="arrow-next"> â</span></a></div></div></div><nav class="onPageNav"><ul class="toc-headings"><li><a href="#elliptic-curve-cryptography">Elliptic Curve Cryptography</a></li><li><a href="#pairing-based-cryptography">Pairing Based Cryptography</a></li><li><a href="#identity-based-encryption">Identity Based Encryption</a></li><li><a href="#post-quantum-cryptography">Post-Quantum Cryptography</a></li><li><a href="#zero-knowledge-proof">Zero Knowledge Proof</a></li><li><a href="#summary">Summary</a></li></ul></nav></div><footer class="nav-footer" id="footer"><section class="sitemap"><a href="/" class="nav-home"><img src="/img/milagro.svg" alt="Apache Milagro" width="50" height="100"/></a><div><h5>Docs< /h5><a href="/docs/milagro-intro.html">Milagro Intro</a><a href="/docs/amcl-overview.html">Apache Milagro Crypto Library</a><a href="/docs/d-ta-overview.html">Decentralized Trust Authority</a><a href="/docs/zkp-mfa-overview.html">Zero Knowledge Proof MFA</a></div><div><h5>Community</h5><a href="../help">Support</a><a href="../docs/contributor-guide">Contributing</a><a href="https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=115529045"; target="_blank" rel="noreferrer noopener">Developer Wiki</a><a href="https://twitter.com/apachemilagro?lang=en"; target="_blank" rel="noreferrer noopener">Twitter</a></div><div><h5>More</h5><a href="/blog">Status</a><a href="https://github.com/apache/incubator-milagro-crypto";>GitHub</a><a class="github-button" href="https://github.com/apache/incubator-milagro"; data-icon="octicon-star" data-count-href="/apache/incubator-milagro-crypto/stargazers" data-show-count="true" data-count-aria-label="# stargazers on GitHub" aria-label="Star this pro ject on GitHub">Star</a></div></section><a href="https://apache.org"; target="_blank" rel="noreferrer noopener" class="fbOpenSource"><img src="/img/oss_logo.png" alt="Apache Incubator" width="170" height="45"/></a><section class="copyright">Copyright © 2019 The Apache Software Foundation. Apache Milagro, Milagro, Apache, the Apache feather, and the Apache Milagro project logo are either registered trademarks or trademarks of the Apache Software Foundation.</section></footer></div></body></html> \ No newline at end of file
Added: incubator/milagro/site/www/docs/milagro-design.html URL: http://svn.apache.org/viewvc/incubator/milagro/site/www/docs/milagro-design.html?rev=1860997&view=auto ============================================================================== --- incubator/milagro/site/www/docs/milagro-design.html (added) +++ incubator/milagro/site/www/docs/milagro-design.html Tue Jun 11 00:28:48 2019 @@ -0,0 +1,147 @@ +<!DOCTYPE html><html lang="en"><head><meta charSet="utf-8"/><meta http-equiv="X-UA-Compatible" content="IE=edge"/><title>Milagro Design · Apache Milagro</title><meta name="viewport" content="width=device-width"/><meta name="generator" content="Docusaurus"/><meta name="description" content="<h2><a class="anchor" aria-hidden="true" id="protocols-and-technology"></a><a href="#protocols-and-technology" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25 c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Protocols and Technology</h2> +"/><meta name="docsearch:language" content="en"/><meta property="og:title" content="Milagro Design · Apache Milagro"/><meta property="og:type" content="website"/><meta property="og:url" content="https://milagro.apache.org/"/><meta property="og:description" content="<h2><a class="anchor" aria-hidden="true" id="protocols-and-technology"></a><a href="#protocols-and-technology" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Protocols and Technology</h2> +"/><meta name="twitter:card" content="summary"/><link rel="shortcut icon" href="/img/favicon.ico"/><link rel="stylesheet" href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.12.0/styles/default.min.css"/><link rel="alternate" type="application/atom+xml" href="https://milagro.apache.org/blog/atom.xml"; title="Apache Milagro Blog ATOM Feed"/><link rel="alternate" type="application/rss+xml" href="https://milagro.apache.org/blog/feed.xml"; title="Apache Milagro Blog RSS Feed"/><script type="text/javascript" src="https://buttons.github.io/buttons.js";></script><script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.5/MathJax.js?config=TeX-MML-AM_CHTML";></script><script src="/js/scrollSpy.js"></script><link rel="stylesheet" href="/css/main.css"/><script src="/js/codetabs.js"></script></head><body class="sideNavVisible separateOnPageNav"><div class="fixedHeaderContainer"><div class="headerWrapper wrapper"><header><a href="/"><img class="logo" src="/img/milagro .svg" alt="Apache Milagro"/><h2 class="headerTitleWithLogo">Apache Milagro</h2></a><div class="navigationWrapper navigationSlider"><nav class="slidingNav"><ul class="nav-site nav-site-internal"><li class="siteNavGroupActive"><a href="/docs/milagro-intro" target="_self">Docs</a></li><li class=""><a href="/help" target="_self">Support</a></li><li class="siteNavGroupActive"><a href="/docs/contributor-guide" target="_self">Contributing</a></li><li class=""><a href="/blog/" target="_self">Status</a></li></ul></nav></div></header></div></div><div class="navPusher"><div class="docMainWrapper wrapper"><div class="container docsNavContainer" id="docsNav"><nav class="toc"><div class="toggleNav"><section class="navWrapper wrapper"><div class="navBreadcrumb wrapper"><div class="navToggle" id="navToggler"><div class="hamburger-menu"><div class="line1"></div><div class="line2"></div><div class="line3"></div></div></div><h2><i>âº</i><span>About Milagro</span></h2><div class="tocToggler" id="to cToggler"><i class="icon-toc"></i></div></div><div class="navGroups"><div class="navGroup"><h3 class="navGroupCategoryTitle">About Milagro</h3><ul class=""><li class="navListItem"><a class="navItem" href="/docs/milagro-intro">Milagro Introduction</a></li><li class="navListItem"><a class="navItem" href="/docs/milagro-crypto">Milagro Crypto</a></li><li class="navListItem"><a class="navItem" href="/docs/milagro-protocols">Milagro Protocols</a></li><li class="navListItem navListItemActive"><a class="navItem" href="/docs/milagro-design">Milagro Design</a></li></ul></div><div class="navGroup"><h3 class="navGroupCategoryTitle">AMCL Library</h3><ul class=""><li class="navListItem"><a class="navItem" href="/docs/amcl-overview">AMCL Overview</a></li><li class="navListItem"><a class="navItem" href="/docs/amcl-c-api">AMCL C API</a></li><li class="navListItem"><a class="navItem" href="/docs/amcl-javascript-api">AMCL JavaScript API</a></li></ul></div><div class="navGroup"><h3 class="navGroupCateg oryTitle">D-TA Node</h3><ul class=""><li class="navListItem"><a class="navItem" href="/docs/d-ta-overview">D-TA Node Overview</a></li><li class="navListItem"><a class="navItem" href="/docs/d-ta-api">D-TA Node API</a></li></ul></div><div class="navGroup"><h3 class="navGroupCategoryTitle">ZKP-MFA Clients/Servers</h3><ul class=""><li class="navListItem"><a class="navItem" href="/docs/zkp-mfa-overview">ZKP-MFA Overview</a></li><li class="navListItem"><a class="navItem" href="/docs/zkp-mfa-api">ZKP-MFA API</a></li></ul></div><div class="navGroup"><h3 class="navGroupCategoryTitle">Project Info</h3><ul class=""><li class="navListItem"><a class="navItem" href="/docs/contributor-guide">Contributor's Guide</a></li></ul></div></div></section></div><script> + var coll = document.getElementsByClassName('collapsible'); + var checkActiveCategory = true; + for (var i = 0; i < coll.length; i++) { + var links = coll[i].nextElementSibling.getElementsByTagName('*'); + if (checkActiveCategory){ + for (var j = 0; j < links.length; j++) { + if (links[j].classList.contains('navListItemActive')){ + coll[i].nextElementSibling.classList.toggle('hide'); + coll[i].childNodes[1].classList.toggle('rotate'); + checkActiveCategory = false; + break; + } + } + } + + coll[i].addEventListener('click', function() { + var arrow = this.childNodes[1]; + arrow.classList.toggle('rotate'); + var content = this.nextElementSibling; + content.classList.toggle('hide'); + }); + } + + document.addEventListener('DOMContentLoaded', function() { + createToggler('#navToggler', '#docsNav', 'docsSliderActive'); + createToggler('#tocToggler', 'body', 'tocActive'); + + var headings = document.querySelector('.toc-headings'); + headings && headings.addEventListener('click', function(event) { + var el = event.target; + while(el !== headings){ + if (el.tagName === 'A') { + document.body.classList.remove('tocActive'); + break; + } else{ + el = el.parentNode; + } + } + }, false); + + function createToggler(togglerSelector, targetSelector, className) { + var toggler = document.querySelector(togglerSelector); + var target = document.querySelector(targetSelector); + + if (!toggler) { + return; + } + + toggler.onclick = function(event) { + event.preventDefault(); + + target.classList.toggle(className); + }; + } + }); + </script></nav></div><div class="container mainContainer"><div class="wrapper"><div class="post"><header class="postHeader"><h1 class="postHeaderTitle">Milagro Design</h1></header><article><div><span><h2><a class="anchor" aria-hidden="true" id="protocols-and-technology"></a><a href="#protocols-and-technology" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Protocols and Technology</h2> +<h3><a class="anchor" aria-hidden="true" id="identity-based-encryption"></a><a href="#identity-based-encryption" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Identity Based Encryption</h3> +<p>M-Pin and Chow Choo are in the class of Identity Based Encryption protocols, which use pairings in their construction. The M-Pin Protocol is intended to replace the well-known Username/Password authentication mechanism which is widely considered to be effectively broken.</p> +<p>The main problem is the existence of a password file on the server, which is commonly stolen and hacked, revealing most user passwords.</p> +<p>The idea behind Milagro's Zero-Knowledge Proof Multi-Factor Authentication (ZKP-MFA) Server is that each registered client is issued with a secret cryptographic key derived from their identity. They then prove to the Milagro ZKP-MFA Server that they are in possession of this key using a zero-knowledge proof protocol, which can be extended to include authenticated key agreement.</p> +<p>This protocol design eliminates the need for any information related to clients, or their keys, to be kept on the authentication server. Should an attacker penetrate the server, it is impossible to deduct any information about end users because it doesn't exist, at least within the authentication system.</p> +<p>Common to both Chow-Choo and M-Pin is that the keys are issued in shares, not as whole keys, by entities called Decentralized Trust Authorities. Only the clients who receive all of the shares from the D-TA's, will ever know their completed whole keys.</p> +<p>Industry commentators have long advocated a multi-factor solution. The novel feature of M-Pin and Chow-Choo is that the cryptographic secrets issued to clients or peers may be safely split up into any number of independent factors.</p> +<p>Each of these factors has the same form; they are points on an elliptic curve. To recreate the original secret, they are simply added together again -- it's as simple as that.</p> +<p>One factor might be derived from a key unlocked from the biometric login (ex: FaceID) which is available as a PIN input on a successful biometric authentication. This 'biometric based' PIN is, on Apple hardware, stored in the secure element of the device (something you are). Another factor might be the remainder token securely stored in the authenticator app on a smartphone (something you have). Yet a final piece can be a PIN or passphrase (something you know), which is secure as the M-Pin client secret cannot be brute force attacked offline.</p> +<h3><a class="anchor" aria-hidden="true" id="decentralized-identity"></a><a href="#decentralized-identity" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Decentralized Identity</h3> +<p>Milagro applications use these identity based protocols in combination with classical cryptosystems where the endpoint generates a public/private key pair and the private key never leaves the application or device.</p> +<p>An entity running a Milagro application attaches the public keys it has generated upon initialization to a self sovereign identity document (ID Document), that only reveals a unique account code as identifier. This ID document is signed by the Milagro and distributed over a decentralized identity system built upon IPFS<sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup>, so each ID Document lives on an immutable, operation-based conflict-free replicated data structure (CRDT), which is accessible to any other Milagro application.</p> +<p><em>For further detail, please see the format specification for ID Documents.</em></p> +<h3><a class="anchor" aria-hidden="true" id="encrypted-envelope"></a><a href="#encrypted-envelope" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Encrypted Envelope</h3> +<p>ID Documents enable messages, called Encrypted Envelopes, containing secrets to be sent between endpoints running Milagro software. This can include clients, servers and peers and Milagro ZKP-MFA Servers, ZKP-MFA clients and Decentralized Trust Authorities. The ID Documents of recipients are available to any endpoint, so their public keys can be used to secure secrets in transit. In the case of digital asset custody, these messages need to be part of a permanent record, available in a decentralized, immutable data structure (like a blockchain). Given the permanence of this data, the privacy design of these immutable records need to account for advances in quantum cryptography.</p> +<p>Messages and immutable records are encrypted with AES-GCM at a 256-bit level with parameters anticipating quantum cryptography. It is necessary to know the recipient's public key, obtained via the ID Document, in order to encapsulate the encryption key for each recipient of the message or entity who has access to the Immutable Record.</p> +<p>SIKE keys pairs are generated locally by endpoints running Milagro software, are not received in shares from D-TAs. SIKE public keys are used by the sender of a message to encapsulate the AES 256-bit key used to create the Encrypted Envelope. An encapsulation takes place once for every recipient and is affixed to the Encrypted Envelope.</p> +<p>BLS signatures handle two jobs. Like SIKE key pairs, BLS signature key pairs are generated locally by endpoints running Milagro software, are not received in shares from D-TAs. The signatures these keys generate enable the non-repudiation of Encrypted Envelopes between endpoints and stored long term as immutable records. This is a classic use case of digital signatures, like PGP signatures over email.</p> +<p><em>For further detail, please see the format specification for Encrypted Envelopes.</em></p> +<p>The other use of BLS signatures is more complex. As described previously, BLS signatures have unique properties. Milagro leverages its own Encrypted Envelope format to enable the BLS ability of splitting signing keys by with a secure mechanism to securely distribute the split BLS signing keys. When delivered securely to the right entities, these part shares of BLS signing keys themselves become signature keys. The thresholds of these signatures can be aggregated securely to produce an aggregated single signature which would have been produced by the original whole signing key prior to the original key being split. This signature can be verified by an aggregated public key.</p> +<p>Another capability is for a public key to be aggregated from multiple public keys in advance of aggregating signatures created by the corresponding private keys. These private keys are generated locally, and never leave the device, vs the method described previously. Signatures made from these keys can themselves be aggregated into a complete signature, verified by the aggregated public key.</p> +<p>These capabilities are well suited to safeguarding secrets with an example in the following section.</p> +<h2><a class="anchor" aria-hidden="true" id="decentralized-trust-authorities-d-ta"></a><a href="#decentralized-trust-authorities-d-ta" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Decentralized Trust Authorities: D-TA</h2> +<p>The Milagro framework protocols rely on Decentralized Trust Authorities for two jobs: Issuing shares of secrets, or safeguarding shares of secrets.</p> +<p>D-TAs can issue shares, or fractions, of Type-3 Pairing private keys to Milagro Applications, such as the Milagro ZKP-MFA Servers or clients or to other D-TAs, which can be any software or hardware applications that have embedded some Milagro code in order derive the functional capabilities.</p> +<p>These clients or peers become the only entities that know the completed whole keys assembled from shares issued by different Decentralized Trust Authorities.</p> +<p>Type-3 pairings were selected as they are the most efficient pairing and will work with non-supersingular pairing-friendly curves.</p> +<p>These operate as \( G_1 \) x \( G_2 \rightarrow G_T \), where \( G_2 \) is a particular group of points, again of the order \( q \), but on a twisted elliptic curve defined over an extension which is a divisor of \( k \).</p> +<p>These curves can be constructed to be a near perfect fit at any required level of security. The pairing protocols within the Milagro framework all work on a Type-3 pairing.</p> +<p>One of the novel aspects of pairing-based cryptography is that deployed secrets are commonly represented as points on an elliptic curve, which are the result of multiplying a known point by a master secret \( s \).</p> +<p>So for example a secret might be of the form \( sP \), where \( P \) is known.</p> +<p>There are a number of interesting things we can do with secrets that have this form, that are not possible with the secrets that arise when using other cryptographic technologies.</p> +<p>For example they can be split into two, into \( s_1P \) and \( s_2P \) where \( s=s_1+s_2 \) and \( sP = s_1P +s_2P \).</p> +<p>In fact they can be just as easily split into multiple parts, just like chopping up a cucumber.</p> +<p>We can also add extra components to create a secret of the form \( s(P_1+P_2) = sP_1+sP_2 \).</p> +<p>It is the flexibility that arises from this form of the secret that allows us to introduce the idea of chopping off a tiny sliver of the secret to support a PIN number.</p> +<p>It also facilitates the concept of <em>Time Permits</em> as discussed in a later section.</p> +<p>Lastly, it enables Decentralized Trust.</p> +<h3><a class="anchor" aria-hidden="true" id="issuing-secrets"></a><a href="#issuing-secrets" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Issuing Secrets</h3> +<p>A Trusted Authority will be in possession of a master secret \( s \), a random element of \( F_q \).</p> +<p>A client secret is of the form \( s.H(ID) \), where ID is the client identity and \( H(.) \) a hash function which maps to a point on \( G_1 \).</p> +<p>From prior art, we assume that \( H \) is modeled as a random oracle where \( H(ID) = r_{ID}.P \)</p> +<p>where \( r_{ID} \in F_q \) is random and \( P \) is a fixed generator of \( G_1 \).</p> +<p>A Milagro ZKP-MFA Server will be issued with \( sQ \), where \( Q \) is a fixed generator of \( G_2 \).</p> +<p>Note that this will be the only multiple of \( s \) in \( G_2 \) ever provided by the TA. Servers will always be associated with their own unique master secrets.</p> +<p>Note that the TA functionality can be trivially decentralized and distributed using a secret sharing scheme, to remove from the overall system a single point of compromise or coercion.</p> +<p>In the simplest possible case there may be two Decentralized Trusted Authorities (D-TAs), each of which independently maintains their own share of the master key.</p> +<p>So \( s=s_1+s_2 \), and each D-TA issues a part-client key to the client \( s_1 H(ID) \) and \( s_2 H(ID) \), which the client, after receiving the shares, adds together to form their full key.</p> +<p>Now even if one D-TA is compromised, the client key is still safe.</p> +<p>In the age of self sovereign identity, any entity can be a Decentralized Trust Authority as long as its Beneficiary trusts it to securely issue shares of secrets, or hold them for safekeeping.</p> +<h3><a class="anchor" aria-hidden="true" id="safekeeping-secrets"></a><a href="#safekeeping-secrets" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Safekeeping Secrets</h3> +<p>A D-TA may act as a Fiduciary over secrets where it can participate in a process to enable a Beneficiary to recover the secret. Using aggregated BLS signatures in a simple example, an entity running Milagro software may engage multiple D-TAs to act as Fiduciaries over its seed value used to generate and back up a cryptocurrency HD Wallet.</p> +<p>As described in<sup class="footnote-ref"><a href="#fn1" id="fnref1:1">[1]</a></sup> the first step is for each D-TA to generate a key pair by choosing \( s k \stackrel{s}{\leftarrow} \mathbb{Z}_{q} \) to compute:</p> +<p>$$ p k \leftarrow g_{2}^{s k}$$</p> +<p>which outputs the \( (p k, s k) \).</p> +<p>The Beneficiary would select which D-TA service providers (acting in concert) it would use to help it generate a secret. Assume a Beneficiary is also a participant in this protocol, it also runs a D-TA and acts as the designated combiner in the protocol.</p> +<p>In advance of creating the HD Wallet seed, a Beneficiary would elicit the services of Decentralized Trust Authorities to act as Fiduciaries in a decentralized secret recovery protocol. The Beneficiary's next step calculates the aggregate public key by running protocol \( \text { KAg }\)({\( p k_{1}, \ldots, p k_{n} \)}) using the D-TA's known public keys as input (who have agreed to act as Fiduciaries to this process) and also its own public key.</p> +<p>The Beneficiary then requests a signature \( \sigma \) on a message \( m \) from each of the D-TAs acting as Fiduciaries, including itself. For each D-TA, singing is a single round protocol.</p> +<p>To finalize setup, each D-TA transmits its signature \( \sigma \) to the Beneficiary (acting as designated combiner). The Beneficiary generates its own signature and combines it with the received D-TA signatures for the final aggregated signature of \( \sigma \leftarrow \prod_{j=1}^{n} s_{j} \).</p> +<p>The final signature is verified against the aggregated public key if the verifier function outputs 1. Assuming so, the setup completes by hashing the aggregated signature where \( H(\tilde{\sigma}) \) is the seed of the HD Wallet.</p> +<p>Assuming the Beneficiary has backed up their BLS signature key, recovering the HD Wallet seed from multiple Fiduciaries becomes as simple as re-running the setup protocol again. It is easy to envision Fiduciary services running D-TAs, responding and authenticating requests for recovering secrets.</p> +<h2><a class="anchor" aria-hidden="true" id="summary"></a><a href="#summary" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Summary</h2> +<h3><a class="anchor" aria-hidden="true" id="pairing-and-pq-cryptography"></a><a href="#pairing-and-pq-cryptography" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Pairing and PQ Cryptography</h3> +<p>Milagro leverages a combination of pairing and post-quantum algorithms to distribute cryptographic operations and split cryptographic parameters, providing a level of security and functionality that is a step forward in when compared to the certificate backed cryptosystems in service today. With pairing cryptography, security systems such as multi-factor authentication using zero knowledge protocols, certificate-less authenticated key agreement with perfect forward secrecy and decentralized secret recovery can be deployed in real world scenarios. AES-256 bit encryption and post-quantum key encapsulation ensure that long-lived data is safe from intrusion, even in the face of a post-quantum adversary.</p> +<h3><a class="anchor" aria-hidden="true" id="decentralized-cryptosystem"></a><a href="#decentralized-cryptosystem" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>Decentralized Cryptosystem</h3> +<p>Bitcoin's blockchain provides an alternative distributed approach to managing a currency without the need for a central bank. With bitcoin, the ledger is distributed, not centralized. Milagro's cryptosystem is decentralized to create the same advantages as a distributed ledger. While architecturally different to the blockchain, Milagro's cryptosystem and the applications built on it are compatible with and can add significant value to cryptocurrencies and other decentralized networks.</p> +<p>Milagro envisions a new class of cryptographic service providers called Decentralized Trust Authorities, or D-TAs for short. The purpose of a D-TA is to independently issue shares, or fractions, of cryptographic keys to Milagro clients and servers and application endpoints which have embedded Milagro cryptographic libraries. D-TA's also operate as 'Fiduciaries', to enable their 'Beneficiaries' to recover secrets in a decentralized manner, without keeping a share of the secret itself. D-TAs operate independently from each other, are isolated in totality, and completely unaware of the existence of other D-TAs.</p> +<h3><a class="anchor" aria-hidden="true" id="no-single-point-of-compromise"></a><a href="#no-single-point-of-compromise" aria-hidden="true" class="hash-link"><svg class="hash-link-icon" aria-hidden="true" height="16" version="1.1" viewBox="0 0 16 16" width="16"><path fill-rule="evenodd" d="M4 9h1v1H4c-1.5 0-3-1.69-3-3.5S2.55 3 4 3h4c1.45 0 3 1.69 3 3.5 0 1.41-.91 2.72-2 3.25V8.59c.58-.45 1-1.27 1-2.09C10 5.22 8.98 4 8 4H4c-.98 0-2 1.22-2 2.5S3 9 4 9zm9-3h-1v1h1c1 0 2 1.22 2 2.5S13.98 12 13 12H9c-.98 0-2-1.22-2-2.5 0-.83.42-1.64 1-2.09V6.25c-1.09.53-2 1.84-2 3.25C6 11.31 7.55 13 9 13h4c1.45 0 3-1.69 3-3.5S14.5 6 13 6z"></path></svg></a>No Single Point of Compromise</h3> +<p>Milagro entities receive issued shares cryptographic keys or signatures and combine them to create the whole completed key or signature, thus becoming the only audience who possess knowledge of the entire key or signature. If D-TAs are under separate organizational controls, current root key compromises and key escrow threats inherent in PKI systems are an order of magnitude harder to achieve in a Milagro cryptosystem. An attacker would need to subvert all independent parties.</p> +<p>In other words, all D-TAs used to generate shares, or fractions, of keys for Milagro clients and servers must be compromised to create the equivalent of a PKI root key compromise. All D-TAs under the threshold needed to recreate a signature would need to be compromised (including the Beneficiary) in order to generate a final signature.</p> +<hr> + + <div class="admonition admonition-note"> + <div class="admonition-heading"> + <h5><div class="admonition-icon"><svg xmlns="http://www.w3.org/2000/svg"; width="14" height="16" viewBox="0 0 14 16"><path fill-rule="evenodd" d="M6.3 5.69a.942.942 0 0 1-.28-.7c0-.28.09-.52.28-.7.19-.18.42-.28.7-.28.28 0 .52.09.7.28.18.19.28.42.28.7 0 .28-.09.52-.28.7a1 1 0 0 1-.7.3c-.28 0-.52-.11-.7-.3zM8 7.99c-.02-.25-.11-.48-.31-.69-.2-.19-.42-.3-.69-.31H6c-.27.02-.48.13-.69.31-.2.2-.3.44-.31.69h1v3c.02.27.11.5.31.69.2.2.42.31.69.31h1c.27 0 .48-.11.69-.31.2-.19.3-.42.31-.69H8V7.98v.01zM7 2.3c-3.14 0-5.7 2.54-5.7 5.68 0 3.14 2.56 5.7 5.7 5.7s5.7-2.55 5.7-5.7c0-3.15-2.56-5.69-5.7-5.69v.01zM7 .98c3.86 0 7 3.14 7 7s-3.14 7-7 7-7-3.12-7-7 3.14-7 7-7z"/></svg></div> See an error in this documentation?</h5> + </div> + <div class="admonition-content"> + <p>Submit a pull request on the development branch of <a href="https://github.com/apache/incubator-milagro";>Milagro Website Repo</a>.</p> +</div></div><!-- +Supported admonition types are: caution, note, important, tip, warning. +--><hr class="footnotes-sep"> +<section class="footnotes"> +<ol class="footnotes-list"> +<li id="fn1" class="footnote-item"><p><a href="https://eprint.iacr.org/2018/483";>Compact Multi-Signatures for Smaller Blockchains</a> <a href="#fnref1" class="footnote-backref">â©</a> <a href="#fnref1:1" class="footnote-backref">â©</a></p> +</li> +</ol> +</section> +</span></div></article></div><div class="docs-prevnext"><a class="docs-prev button" href="/docs/milagro-protocols"><span class="arrow-prev">â </span><span>Milagro Protocols</span></a><a class="docs-next button" href="/docs/amcl-overview"><span>AMCL Overview</span><span class="arrow-next"> â</span></a></div></div></div><nav class="onPageNav"><ul class="toc-headings"><li><a href="#protocols-and-technology">Protocols and Technology</a><ul class="toc-headings"><li><a href="#identity-based-encryption">Identity Based Encryption</a></li><li><a href="#decentralized-identity">Decentralized Identity</a></li><li><a href="#encrypted-envelope">Encrypted Envelope</a></li></ul></li><li><a href="#decentralized-trust-authorities-d-ta">Decentralized Trust Authorities: D-TA</a><ul class="toc-headings"><li><a href="#issuing-secrets">Issuing Secrets</a></li><li><a href="#safekeeping-secrets">Safekeeping Secrets</a></li></ul></li><li><a href="#summary">Summary</a><ul class="toc-headings"><li><a href="#pairing-and-pq-cryptography">Pairing and PQ Cryptography</a></li><li><a href="#decentralized-cryptosystem">Decentralized Cryptosystem</a></li><li><a href="#no-single-point-of-compromise">No Single Point of Compromise</a></li></ul></li></ul></nav></div><footer class="nav-footer" id="footer"><section class="sitemap"><a href="/" class="nav-home"><img src="/img/milagro.svg" alt="Apache Milagro" width="50" height="100"/></a><div><h5>Docs</h5><a href="/docs/milagro-intro.html">Milagro Intro</a><a href="/docs/amcl-overview.html">Apache Milagro Crypto Library</a><a href="/docs/d-ta-overview.html">Decentralized Trust Authority</a><a href="/docs/zkp-mfa-overview.html">Zero Knowledge Proof MFA</a></div><div><h5>Community</h5><a href="../help">Support</a><a href="../docs/contributor-guide">Contributing</a><a href="https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=115529045"; target="_blank" rel="noreferrer noopener">Developer Wiki</a><a href="https://twitter.com/apachemila gro?lang=en" target="_blank" rel="noreferrer noopener">Twitter</a></div><div><h5>More</h5><a href="/blog">Status</a><a href="https://github.com/apache/incubator-milagro-crypto";>GitHub</a><a class="github-button" href="https://github.com/apache/incubator-milagro"; data-icon="octicon-star" data-count-href="/apache/incubator-milagro-crypto/stargazers" data-show-count="true" data-count-aria-label="# stargazers on GitHub" aria-label="Star this project on GitHub">Star</a></div></section><a href="https://apache.org"; target="_blank" rel="noreferrer noopener" class="fbOpenSource"><img src="/img/oss_logo.png" alt="Apache Incubator" width="170" height="45"/></a><section class="copyright">Copyright © 2019 The Apache Software Foundation. Apache Milagro, Milagro, Apache, the Apache feather, and the Apache Milagro project logo are either registered trademarks or trademarks of the Apache Software Foundation.</section></footer></div></body></html> \ No newline at end of file
