[cap-talk] use of hashcodes?

[David Wagner]

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.  It's important to understand how ETags work,
as specified in the HTTP protocol, before selecting a cryptographic
primitive to use for computing ETags.

ETags is part of HTTP.  The server can optionally send an ETag together
with its HTTP response.  The ETag is an opaque value that's much shorter
than the response itself (say, 256 bits or so).  The client then uses
this to detect whether the page has changed or not.  If the ETag is
the same, then the client can use its cached copy of the page, without
downloading the page a second time.  The ETag is an opaque value that
is not interpreted by clients.  The semantic requirement on servers is
that the ETag should be the same for two requests only if the content
(the response) to both would be identical.

  http://en.wikipedia.org/wiki/HTTP_ETag

Since ETags are not interpeted by the client (or by anyone other
than the server), there is little point in using digital signatures
or other public-key algorithms here.  It's not a general-purpose
mechanism for communicating information from one party to another;
it's a special-purpose mechanism for caching.  A hash or MAC is
a perfect primitive for this.

I want to emphasize that I am talking specifically about Waterken's use
of ETags here.  I'm not talking about anything else.  I get the sense
that you're trying to argue about what is the "best" kind of cryptographic
algorithm in the abstract, rather than the best cryptographic primitive to
use specifically for generating ETags values.  I'm not really interested
in debating about other applications of cryptography, other than ETags,
right now; I'll just request that if you are talking about some other
scenario, let's be clear that any criticisms you might have about that
other scenario do not apply to ETags.

David Barbour  wrote:
>Of course, HMAC is a symmetric authentication: anyone who can
>authenticate a signature also has capability to forge one, which
>prevents a number of useful distribution and delegation patterns.

That may be, but that's not relevant to ETags, so that's neither here
nor there.  Symmetric authentication is fine for ETags, because an ETag is
not a signature, and no one ever needs to "verify" an ETag.  For instance,
as specified in the HTTP protocol and implemented in modern web browsers,
the client does not "verify" ETags values.  An ETag is not intended to
serve as a digital signature on the HTTP response: it exists only for
caching purposes.

>If the main goal is to distribute the Stamp capability, [...]

That is not the main goal of ETags.

>Known forms of asymmetric hash-based authentication require signing
>the hash, and are thus vulnerable to the error described in the
>aforementioned document.

That's not relevant to ETags.

>Apparently you didn't bother reading the remainder of my post. How
>much good does a larger Bytes/Second do you if it simply means you end
>up processing more Bytes?

I did read it, and it wasn't relevant to ETags.  Using a hash or MAC
for ETags does not mean you have to process more Bytes than some other
approach to computing ETags.  (Using a public-key signature algorithm to
compute ETags would not reduce the number of bytes you have to process
to compute the ETag.)

>> Moreover, caching using ETags has important performance benefits, so I'd
>> expect that the net performance impact of Waterken's use of SHA256-HMAC
>> for ETags is a win for performance, not a loss.
>
>Compared to what, exactly?

Compared to not using ETags.  Enabling ETags improves caching
(compared to not enabling ETags), which improves performance.

>> That's a different question, and it's not relevant to Waterken's ETags.
>> Waterken's use of SHA256-HMAC for ETags is a very specific use case,
>> one where hashing (MACing) is entirely appropriate, and where public-key
>> cryptography (what you are calling "sealers") would not be.
>
>Sure, it's relevant. The environment is the ultimate arbiter of which
>use-cases are relevant. Waterken is clearly an attempt to architect an
>environment for 'general purpose' usage.

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).  Yes, Waterken enables
general-purpose applications.  ETags is just one small part of Waterken.
ETags is a special-purpose mechanism.  ETags is not a general-purpose
mechanism for general-purpose secure communication or general-purpose
secure coordination or general-purpose secure delegation (Waterken has
other mechanisms for those, but that's not what ETags does).  ETags is
a special-purpose mechanism, one that is a very specific use case for
cryptography.  The constraints and requirements that the HTTP protocol
imposes upon the cryptographic algorithms used to generate ETags are
fairly special-purpose, and are not the same as the requirements on
cryptographic algorithms that come up in many other uses of cryptography.

ETags has nothing to do with "distributed transaction capabilities".
It's a very specific mechanism specified in the HTTP standard.
Waterken uses this piece of the HTTP protocol to improve Waterken's
performance.

>The goal isn't to find an algorithm optimal for all scenarios. The
>goal is to architect an environment that is near-optimal for most
>scenarios and is capable of supporting the rest.

That goal has nothing to do with the very narrow question of what is the
best way to generate ETags values.  For the very specific use case of
generating ETags, Waterken has (in my opinion) a well-thought-out and
appropriate design.

>But Waterken
>is hindered by assuming a capability-hostile environment. Most of the
>work must be performed at a common Server rather than cooperatively
>distributed among servers and browsers.

This has nothing to with what is the best cryptographic algorithm
to use for generating ETags.