<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 9, 2017 at 1:51 PM, Jack N. <span dir="ltr"><<a href="mailto:j.a.w.n@tutanota.com" target="_blank">j.a.w.n@tutanota.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
9. Apr 2017 15:06 by <a href="mailto:phill@hallambaker.com" rel="noopener noreferrer" target="_blank">phill@hallambaker.com</a>:<div><div class="gmail-h5"><br><br><blockquote class="gmail-m_-3079766646267210789tutanota_quote" style="border-left:1px solid rgb(147,163,184);padding-left:10px;margin-left:5px"><div><div style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 8, 2017 at 2:01 PM, Harlan Lieberman-Berg <<a rel="noopener noreferrer" href="mailto:hlieberman@setec.io" target="_blank">hlieberman@setec.io</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Phillip Hallam-Baker <<a rel="noopener noreferrer" href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> writes:<br>
> Making such a scheme usable is somewhat tricky because we would want to<br>
> make the shares used to secure the key to be as small as possible for<br>
> convenience which indicates 128 bit work factor for the master key.<br>
<br>
Why not simply use Shamir's Secret Sharing? The security properties are<br>
much stronger (SSS is information-theoretic secure such that a (k,n)<br>
construction reveals no information with k-1 shares known. The size is<br>
fairly minimal too; IIRC, each share is no larger than the key itself<br>
(thus, the total construction is n*bit size).<br></blockquote><div><br></div><div style="font-size:small">I am using Shamir Secret Sharing. But that only gets you from a set of key shares to a master secret. You still have to get from the master secret to the encryption key.</div><div style="font-size:small"><br></div><div style="font-size:small">If you use 256 bits for the master key you end up with 256 bit shares.</div></div></div></div></blockquote><p><br></p></div></div><p>Couldn't the SSShares reconstruct the master secret which is the encryption key?</p><p>the master secret needn't be another step removed from the shares.</p><p><br></p><p>If you use a 256bit for the master key you dont end have to have 256bit shares, or did you mean 256shares?</p><p><br></p><p>But i believe the normal approach to solving the problem, i think you are trying to solve is to use asymmetric encryption where the secret shares reconstruct the asymmetric private key info. Tho i fear you may have the same problem again if you have a fundamental misunderstanding on shamir sharing and prime secret size. </p></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">No, that is not the problem I am trying to solve. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Lets say we are doing RSA 4096. My scheme still allows me to escrow the key using a set of 128 bit shares as the only thing the user keeps track of.. I encrypt the RSA private key in AES 256 and store it on a cloud service as the first step.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The steps for recovery are thus as follows:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Reconstruct the 128 bit master secret from the shares.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">2) Take the UDF fingerprint of the master secret, this is the identifier used to store the recovery blob in the cloud.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">3) Use HKDF (RFC 5869) to derive the 256 bit key unwrapping key</div><br></div><div><div class="gmail_default" style="font-size:small">4) Use AES Key wrap (RFC 3394) to recover the key used to encrypt the recovery blob.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The last step is only necessary because my content encryption scheme is designed to minimize the number of code paths. Since key wrap is needed sometimes, I require it always so as to simplify implementation.</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">What I am looking to do is to achieve a brute force work factor of 2^128 but to present the higher 2^256 Work Factor for anything that is faster than brute force. It seems like to me that anything faster than brute force is going to depend on some relationship between keys but I can't prove that</div><br></div><div> </div></div><br></div></div>