[cap-talk] use of hashcodes?

[David Barbour]

On Mon, Feb 22, 2010 at 8:54 AM, David Wagner <daw at cs.berkeley.edu> wrote:
> David, I feel like we're talking past each other.  I want to check if
> you're familiar with the ETags mechanism in particular, because it is a
> very specific mechanism. [...] ETags is a special-purpose mechanism,
> one that is a very specific use case for cryptography.

Ben Laurie's follow up matches the understanding I had prior to your
explanation. ETags are a cache coherence cookie.

I'm curious as to why you believe this to be a 'use case for
cryptography'. Precisely which attack does having a 'big'
cryptographically-secure ETag prevent?

>
> I'm not really interested in debating about other applications
> of cryptography, other than ETags, right now;

To be clear: Raould asked about use of hash codes for security. While
he did mention ETags, his question was not limited to them. Saying
"this has nothing to do with ETags" repeatedly, as you have been doing
from the very beginning, isn't of much help in answering Raould's OP
question. If you are not interested in discussing other applications
of hash codes for security, then simply don't.

>
> I think you have misunderstood.  You are conflating the user-level
> applications that Waterken wants to support with the special-purpose
> nature of ETags (one small component in Waterken).

I think you are conflating a general question about "using hashcodes
wrt making promises about the behaviuor/quality/security of a system"
with a question about one special purpose component in HTTP and
Waterken.

>
> That goal has nothing to do with the very narrow question of what is the
> best way to generate ETags values.

Who asked this very narrow question?

It seems you dodged this "very narrow question" when you answered
"Compared to not using ETags" when I asked how using HMAC for ETags
compares for performance, so I don't think you're actually interested
in answering it.

Anyhow, assuming ETags means assuming HTTP. I think that's your big
performance drain, right there. Of course, you're effectively stuck
with HTTP - and the limitations of dynamic HTML - unless you also
create a 'Waterken' browser or plugin (or some other alternative).