Add function for generating validation signatures.

src/trusted/validator/caching/hashing_interface.h

+/*
+ * Copyright (c) 2012 The Native Client Authors. All rights reserved.
+ * Use of this source code is governed by a BSD-style license that can be
+ * found in the LICENSE file.
+ */
+
+#ifndef NATIVE_CLIENT_SRC_TRUSTED_VALIDATOR_CACHING_HASHING_INTERFACE_H_
+#define NATIVE_CLIENT_SRC_TRUSTED_VALIDATOR_CACHING_HASHING_INTERFACE_H_
+
+#include "native_client/src/include/nacl_base.h"
+
+EXTERN_C_BEGIN
+
+struct HashingInterface {
+  void *(*create)(const unsigned char *key, const unsigned int length);

[bsy, 2012/02/22 01:43:35]

key length should not be an input parameter per se, since using short keys is
bad etc.  an hmac key should be the same size as the merkle-damgaard
construction hash function's compression function's feedback register size.

there should be some kind of interface query (or just a size_t parameter) to
obtain the desired key length, since we are being abstract about what the actual
hashing algorithm might be.

also, i suggest naming this function pointer create_context or create_ctx;
prefer changing ctx below to context to make the pairing obvious.

[Nick Bray (chromium), 2012/02/22 03:07:28]

1) HMAC is spec'ed to accept keys of arbitrary size.  It pads or hashes the key
as needed to match the algorithm's block size.  Small keys are easier to guess,
but not bad in any other way.

2) The crux is that if the interface demands a key of a specific length, it's
unclear what should be done if the interface makes an "unreasonable" demand.  As
I am planning, Chrome will provide a 32-byte number, but I don't want to bake
that into this interface.

3) This is consistent with the Chrome src/crypto/ directory.

[bsy, 2012/02/22 18:28:15]

just because hmac is spec'd to accept keys of arbitrary size doesn't mean that
this information must be hidden.  in particular, keys longer than the feedback
register length are no better than ones equal to the register length (assuming
full entropy keys) because the spec just says to hash the long keys.  the spec
is designed to make less-than-fully-informed uses reasonable.  since secure
random bits can be expensive to obtain, it is generally a good idea for this
information to be exposed.  yes, short keys aren't bad in other ways.

note that this value is a max-useful key length -- which also tells relying code
on the maximum security available -- and not a required key length, as you may
have mistakenly inferred.

+  void (*update)(void *ctx, const unsigned char *data,
+                 const unsigned int length);
+  void (*end)(void *ctx, unsigned char *data, unsigned int *length,

[bsy, 2012/02/22 01:43:35]

suggest use common terminology -- instead of "end", use "digest".

[Nick Bray (chromium), 2012/02/22 03:07:28]

Done.

+              const unsigned int max_length);

[bsy, 2012/02/22 01:43:35]

max usable max_length is also a hash parameter.

might want to look at google3/security/util/hmac.h

[Nick Bray (chromium), 2012/02/22 03:07:28]

I don't follow.

[bsy, 2012/02/22 18:28:15]

the max length input parameter is the buffer size (const not needed for basic
types, btw), but the API doesn't say what the maximum usable hash length is. 
the only way to discover it is to hash something and provide a huge value for
max_length.  the out parameter, length, presumably will yield the hash output
length.  when the max_length is shorter than the hash output length, presumably
what is output is a truncated hash.  for our (current) uses, maybe it doesn't
matter much, but as an API it'd be nicer to know what is the maximum security
available (hash output length).

the google3 reference is a pointer for you to look at the internal,
non-open-sourced implementation for API design comparison.  what you're doing
isn't hmac per se, but it's a sufficiently thin wrapper that i'm not sure there
is (or ought to be) a difference.

+};
+
+EXTERN_C_END
+
+#endif /* NATIVE_CLIENT_SRC_TRUSTED_VALIDATOR_CACHING_HASHING_INTERFACE_H_ */