<div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Mon, 30 Apr 2018, 22:39 Phillip Hallam-Baker, <<a href="mailto:phill@hallambaker.com" target="_blank" rel="noreferrer">phill@hallambaker.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-size:small">I am just working on the DARE (Data At Rest Enhancement) spec and was interested to know what the Quantum difficulty of a particular attack would be.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The basic concept of DARE is that we perform one master key agreement and then apply the result to multiple Enhanced Data Sequences:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">"<span style="font-family:Calibri,sans-serif;font-size:11pt">A DARE message
MAY contain multiple Enhanced Data Sequences. The message body, cloaked
headers, annotations and signature values are all presented as Enhanced Data
Sequences"</span></div><div class="gmail_default" style="font-size:small"><span style="font-family:Calibri,sans-serif;font-size:11pt"><br></span></div><div class="gmail_default" style="font-size:small"><span style="font-family:Calibri,sans-serif;font-size:11pt">The reason I like this approach is that it provides a simple and straightforward means of supporting features that are really essential in application messaging such as the ability to encrypt the subject line and message body separately and to encrypt signature values etc.</span></div><div class="gmail_default" style="font-size:small"><span style="font-family:Calibri,sans-serif;font-size:11pt"><br></span></div><div class="gmail_default" style="font-size:small"><span style="font-family:Calibri,sans-serif;font-size:11pt">Unlike in other formats, each Enhanced Data Sequence is encrypted under a unique key and IV. These are derived from the Master Key by means of HKDF and a salt that is unique to that EDS.</span></div><div class="gmail_default" style="font-size:small"><span style="font-family:Calibri,sans-serif;font-size:11pt"><br></span></div><div class="gmail_default" style="font-size:small"><span style="font-family:Calibri,sans-serif;font-size:11pt"><br></span></div><div class="gmail_default" style="font-size:small"><span style="font-family:Calibri,sans-serif;font-size:11pt">So if we are constructing a message we can very easily ensure that each salt is unique: Just use a counter and increment by 1 for each EDS we generate. </span></div><div class="gmail_default" style="font-size:small"><span style="font-family:Calibri,sans-serif;font-size:11pt"><br></span></div><div class="gmail_default" style="font-size:small"><span style="font-family:Calibri,sans-serif;font-size:11pt">But when we get to the message body, we might want to be able to effectively erase the body by erasing the salt value:</span></div><div class="gmail_default" style="font-size:small"><span style="font-family:Calibri,sans-serif;font-size:11pt"><br></span></div><div class="gmail_default" style="font-size:small"><span style="font-family:Calibri,sans-serif;font-size:11pt">"</span><span style="font-family:Calibri,sans-serif;font-size:11pt">For data
erasure to be effective, the salt must be constructed so that the difficulty of
recovering the key is sufficiently high that it is infeasible. For most purposes,
a salt with 128 bits of appropriately random data will be sufficient."</span></div><div class="gmail_default" style="font-size:small"><span style="font-family:Calibri,sans-serif;font-size:11pt"></span></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif">I don't know what DARE's goals are, or why you'd need to erase the body of what's described as a message more efficiently than erasing the message itself, but it sounds like you want this salt to act like a key. So why not just store a "message body" key in a new EDS, and erase that sequence instead? That way no implementer will get confused about the mixed purpose of the salt or have to reason about whether it's safe.</span><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Now the neat thing here is that even if I am using AES-256, a salt of 128 bits is almost certainly sufficient because it is a 'hard' workfactor. We are literally deleting that part of the key. 2^128 is an infeasible work factor, the only reason to go higher is because we worry about the algorithm not being as good as we think, not because someone could build a machine that could break a workfactor that size.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Or can they? Does Shorr's algorithm mean I need to go longer or does the same argument apply?</div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">You appear to be talking about hashes only. Where does Shor's algorithm come into it?</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Mark</div></div>