Nikos Mavrogiannopoulos nmav@gnutls.org writes:
Do you want me to contact him for clarification? However, I think that the file's license overrides the library license.
It would be nice if the licensing were crystal clear, and I'd like to have a correct description also in the copyright section of the manual.
On 10/03/2012 10:27 PM, Niels Möller wrote:
+static void +fill_gost94_sbox (uint32_t out[4][256], const uint8_t src[8][16])
Maybe this should be moved to a separate file gost-data, to generate the tables during the build process?
Is it really needed?
It's not absolutely necessary, but I think it's nice to include code for generating various magic tables, like in aesdata.c, shadata.c, gcmdata.c, etc. Even if it's not done consistently for *all* such tables.
I was thinking to even remove the fill_gost94_sbox() function.
I don't think that function should be included in the built library. But if we have a gostdata tool, it obviously belongs there.
Can you explain briefly what this gost94_sbox and gost94_sbox_cryptpro is about?
I can only speculate on that because I'm not familiar with the standard. However the gosthash is based on the gost encryption algorithm which had no fixed sboxes. You could have different application areas of the algorithm that used different sboxes.
For my use-case the original sboxes are ok. I just kept the additional ones. I could remove them.
If no one else comes up with a use case for the "cryptpro" sboxes, I think we can leave them out for now.
treat them as two distinct hash functions (one could still share internal functions like gost_block_compress, and pass appropriate sboxes as an argument).
That would deviate from the format of the other hash functions in nettle.
I was thinking that the adveertised interface would be gost_hash_* and gost_hash_cryptpro_*, each following the same conventions as the other hash functions. The shared gost_block_compress, with an sbox argument, would either be purely internal, or a gost-specific piece of the advertised interface.
+#undef GENERATE_GOST_LOOKUP_TABLE
I don't think GENERATE_GOST_LOOKUP_TABLE belongs in the header file.
Why would it be better?
It seemed like an implementation detail to me (maybe that's not how it was intended?). If it is needed at all, I think it belongs in config.h or possibly nettle-internal.h or gost-internal.h.
The header uses this definition.
Only to make the prototype for gost_init_table conditional. But that function can be declared unconditionally (if we want it at all).
btw. I've renamed the algorithm to gosthash94, to allow for a future gost encryption algorithm.
I guess the "94" is the year. So a gost94 encryption algorithm is already defained, from the same time?
I should probably read RFC 5831 and any other relevant reference material before asking more questions.
Regards, /Niels