[Cryptography] Data erasure by erasure of a salt

[Mark Steward]

On Mon, 30 Apr 2018, 22:39 Phillip Hallam-Baker, <phill at hallambaker.com>
wrote:

> 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.
>
> The basic concept of DARE is that we perform one master key agreement and
> then apply the result to multiple Enhanced Data Sequences:
>
> "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"
>
> 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.
>
> 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.
>
>
> 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.
>
> But when we get to the message body, we might want to be able to
> effectively erase the body by erasing the salt value:
>
> "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."
>

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.


> 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.
>
> Or can they? Does Shorr's algorithm mean I need to go longer or does the
> same argument apply?
>

You appear to be talking about hashes only. Where does Shor's algorithm
come into it?


Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20180501/0c92c158/attachment.html>