<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 1:13 PM, Tony Arcieri <span dir="ltr"><<a href="mailto:bascule@gmail.com" target="_blank">bascule@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Tuesday, August 26, 2014, Jonathan Moore <<a href="mailto:moore@eds.org" target="_blank">moore@eds.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
I am but I still need to encrypt the documents.</div></blockquote><div><br></div></div><div>In past capability-based systems I've made that work like this[1] (where I don't want them to be content addressable) I've used a random nonce.</div>
</blockquote><div><br></div><div>This is what I currently do.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>If you're worried about nonce repetition due to a bad RNG, you can use something like the current time for part of the nonce in addition to RNG. That's cheaper than computing a content or ciphertext hash.</div>
</blockquote><div><br></div><div>I considered this approach, and yes it is cheaper, but does not have the same properties. If I am correct, with my proposal, in the worst case, loses only semantic security. Just mixing in the time still has failure cases of nonce reuse.</div>
<div><br></div><div>My goal in the conversation is to discuss the solution space of removing strong random requirements form cryptosystems. I do have a project, with working code, where I might apply some of this; but right now I am just thinking about general solutions practical issues of low entropy.</div>
<div><br></div><div>I don't think these just wanky considerations. We have seen that embedded system and VMs often boot up in an initial state where there may not be a reliable time source or much entropy.</div><div>
<br>
</div><div>I do agree that in many cases your suggestions will be more efficient but think that the approach I have outlined is interesting line of thought.</div><div><br></div><div>-Jonathan</div><div><br></div><div><br>
</div></div></div></div>