RE: Threat Model
Shai Halevi wrote:
> As a cryptographer, I have a problem with the approach of trying to
> identify the "security needs" of an application, and then find the most
> efficient piece of crypto that addresses these needs and nothing more.
> I am very skeptical of our ability to understand the real "security
> needs", and claims that some form of attack "cannot really be useful
> to an attacker" commonly turn out to be wrong.
>
> Instead, I prefer the approach of using the "strongest possible piece
> of crypto", under reasonable performance constraints. In most cases the
> crypto is not the most expensive piece anyway. And even when it is the
> most expensive piece, advances in technology diminish the expense, but
> security risks are something that you are stuck with for a long time.
>
> Specifically for our case, I seriously doubt that the difference
> between using EME and using "LRW with pre-mixing" (which is what Jim
> describes) will be much noticeable for any application. And with EME
> you don't have to resort to claims that "this looks random to any
> application not specifically checking for this".
I am certainly sympathetic with the above arguments.
However, EME has some pretty big holes:
1. An attacker can observe any block written and determine if it
matches or does not match any previous write to the same block.
2. An attacker may tamper with any block and cause the reader
to see random corrupt data.
3. An attacker may tamper with any block using a replay of previously
observed data.
4. An attacker can observed the timing and address distribution of all
reads and writes.
To me these seem like a larger concern than what you raise above.
So it seems at least worth asking the question if it makes sense
to double the cost of the algorithm to reduce a ten foot hole
to a nine foot hole. But I don't have a problem if the answer is yes.
> Well, in this case I guess the requirement would be unforgeability of
> ciphertext (except with respect to a low setting of the security
> parameter, since you talk about a 64-bit authentication tag).
>
> [...]
>
> The easiest thing would be to add a 64-bit message-authentication-code
> on top of the encryption. Optimizations are possible, of course (e.g.,
> use some variant of OCB).
I was specifically talking about the addition of the 64 bit "Block guard"
which I believe is under discussion in T11. Perhaps someone can be more
specific here.
It seems likely that use of the block guard will become the norm for
high end storage. Although, to be transparent, the block guard bits
must be encrypted and decrypted along with the data bits, there is
a difference. If the block guard bits are incorrect, this will be
detected and cause a fatal error. This is unlike the data bits,
which if incorrect will be passed to the application without checking.
64 bits of security should be sufficient provided that the only possible
attacks are on-line attacks, and that a single wrong guess causes a fatal
error. This would be the case here.
As such, the requirement is that any modification of the data (other than
replay) results in a probability no more than 2^-64 that the result
will pass the block guard check. This is a potentially easier requirement
to meet that the requirement that the decrypted data look random. However,
requiring that the decrypted data (including the block guard) look random
is certainly sufficient.