Add function for generating validation signatures.

Add function for generating validation signatures.

BUG= http://code.google.com/p/nativeclient/issues/detail?id=2515
TEST= ./scons run_validation_caching_test

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

did you intend the arm changes to be part of this CL?

https://chromiumcodereview.appspot.com/9430028/diff/1/src/trusted/validator/c...
File src/trusted/validator/caching/hashing_interface.h (right):

https://chromiumcodereview.appspot.com/9430028/diff/1/src/trusted/validator/c...
src/trusted/validator/caching/hashing_interface.h:15: void *(*create)(const
unsigned char *key, const unsigned int length);
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.

https://chromiumcodereview.appspot.com/9430028/diff/1/src/trusted/validator/c...
src/trusted/validator/caching/hashing_interface.h:18: void (*end)(void *ctx,
unsigned char *data, unsigned int *length,
suggest use common terminology -- instead of "end", use "digest".

https://chromiumcodereview.appspot.com/9430028/diff/1/src/trusted/validator/c...
src/trusted/validator/caching/hashing_interface.h:19: const unsigned int
max_length);
max usable max_length is also a hash parameter.

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

https://chromiumcodereview.appspot.com/9430028/diff/1/src/trusted/validator/c...
File src/trusted/validator/caching/validation_caching_test.cc (right):

https://chromiumcodereview.appspot.com/9430028/diff/1/src/trusted/validator/c...
src/trusted/validator/caching/validation_caching_test.cc:13: void *
TestHashCreate(const unsigned char *key, const unsigned int length) {
either "void* TestHashCreate" or "void *TestHashCreate" so it doesn't look like
multiplication.

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

FYI, a late night discussion with BradN gave me the idea of merging this
interface w/ the interface for querying the database.  With this approach the
internal details of hashing (digest size) would not be exposed to sel_ldr.

Yes, the ARM change was intentional.  I am making sure this code works for ARM -
it may not be safe, but all the nuts-and-bolts tests should pass.

https://chromiumcodereview.appspot.com/9430028/diff/1/src/trusted/validator/c...
File src/trusted/validator/caching/hashing_interface.h (right):

https://chromiumcodereview.appspot.com/9430028/diff/1/src/trusted/validator/c...
src/trusted/validator/caching/hashing_interface.h:15: void *(*create)(const
unsigned char *key, const unsigned int length);
On 2012/02/22 01:43:35, bsy wrote:
> 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.

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.

https://chromiumcodereview.appspot.com/9430028/diff/1/src/trusted/validator/c...
src/trusted/validator/caching/hashing_interface.h:18: void (*end)(void *ctx,
unsigned char *data, unsigned int *length,
On 2012/02/22 01:43:35, bsy wrote:
> suggest use common terminology -- instead of "end", use "digest".

Done.

https://chromiumcodereview.appspot.com/9430028/diff/1/src/trusted/validator/c...
src/trusted/validator/caching/hashing_interface.h:19: const unsigned int
max_length);
On 2012/02/22 01:43:35, bsy wrote:
> max usable max_length is also a hash parameter.
> 
> might want to look at google3/security/util/hmac.h

I don't follow.

https://chromiumcodereview.appspot.com/9430028/diff/1/src/trusted/validator/c...
File src/trusted/validator/caching/validation_caching_test.cc (right):

https://chromiumcodereview.appspot.com/9430028/diff/1/src/trusted/validator/c...
src/trusted/validator/caching/validation_caching_test.cc:13: void *
TestHashCreate(const unsigned char *key, const unsigned int length) {
On 2012/02/22 01:43:35, bsy wrote:
> either "void* TestHashCreate" or "void *TestHashCreate" so it doesn't look
like
> multiplication.

Done.

[bsy, 2012-02-22 18:28:14]

https://chromiumcodereview.appspot.com/9430028/diff/1/src/trusted/validator/c...
File src/trusted/validator/caching/hashing_interface.h (right):

https://chromiumcodereview.appspot.com/9430028/diff/1/src/trusted/validator/c...
src/trusted/validator/caching/hashing_interface.h:15: void *(*create)(const
unsigned char *key, const unsigned int length);
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.

https://chromiumcodereview.appspot.com/9430028/diff/1/src/trusted/validator/c...
src/trusted/validator/caching/hashing_interface.h:19: const unsigned int
max_length);
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.

[Mark Seaborn, 2012-09-27 02:30:13]

Mind if I close this issue (since it's in my queue)?  This change was superseded
by doing the hashing on the Chrome side...