<div dir="ltr"><div class="gmail_default" style="font-size:small">I am using Shamir secret sharing as a recovery mechanism for private keys and would like to extend this to recover quantum resistant keys. As a result, I need a nice round prime greater than 2^256.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Finding a nice round prime smaller than 2^256 is easy, 2^255-2^19-1. But I need 2^256-x. I was looking for lists of Solinas primes but can't find one with what I need.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Anyone got a pointer?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For public key crypto, AES256 with a key derived from a 128 bit secret seems sufficient as with Quantum attacks in view, I can't expect my public key to present a higher work factor than 2^128. Since the size of recovery shares does matter quite a bit, I think 128 bit shares are appropriate.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For quantum, I really need 256 bits to justify the exercise at all. Now I could just do two 128 bit polynomials but that seems like a hack to me and I would have to describe and test both code paths.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I have completely re-written most of the Mesh documentation. You can review the first installment of this work here. DARE (Data At Rest Encryption) message and container are designed to work together to support incremental encryption and authentication. Think of it as blockchain that you can use to encrypt as well.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So imagine you have a server, it writes 100 entries to the log every second. We do not want to do a key exchange for every entry as these would be larger than the log entries. The DARE format allows us to do one key exchange when the server starts and then use it for as long as it likes. It is even possible for multiple servers to write to the same log under separate master keys.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><div class="gmail_default"><a href="http://mathmesh.com/Documents/draft-hallambaker-dare-message.html">http://mathmesh.com/Documents/draft-hallambaker-dare-message.html</a><br></div><div class="gmail_default"><a href="http://mathmesh.com/Documents/draft-hallambaker-dare-container.html">http://mathmesh.com/Documents/draft-hallambaker-dare-container.html</a></div><div class="gmail_default"><br></div><div class="gmail_default">I may well cut out some of the container types. At the moment there are five different types depending on whether they have a chained digest, Merkle digest or no digest and whether they have a tree index or not. The chain is probably not very useful.</div><div class="gmail_default"><br></div><div class="gmail_default"><br></div></div><div class="gmail_default" style="font-size:small">I am now writing the fun document that describes all the features that are new to PKI in the Mesh. They are not new to crypto of course but we have not moved the state of crypto we use in the public domain much since PGP made public key crypto for email practical apart from BitCoin adopting 30 year old hash chain technology. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The new technology includes:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* Shamir secret sharing for recovery of master private keys.</div><div class="gmail_default" style="font-size:small">* Distributed key generation/Proxy re-encryption to support group access to data.</div><div class="gmail_default" style="font-size:small">* Co-generation of public key pairs to mitigate risks of weak key generation.</div><div class="gmail_default" style="font-size:small">* Quantum resistant signatures to enable recovery in the case someone makes quantum computing practical.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I would much appreciate review of these documents and if we are going to make them industry standards, expressions of interest in the IETF.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Designing a new cryptographic message format is not something to be done lightly. PKCS7 has served us well. BUT, I can't add even half of these capabilities to PKCS7 without losing backwards compatibility. And it is difficult enough coping with the complexity resulting from the cryptographic issues without also having to consider backwards compatibility. If people really really want to add these capabilities back into legacy formats, lets at least do the design in a clean environment.</div></div>