On 10/03/2012 10:27 PM, Niels Möller wrote:
- Copyleft:
- I hereby release this code into the public domain. This applies worldwide.
- I grant any entity the right to use this work for ANY PURPOSE,
- without any conditions, unless such conditions are required by law.
- */
The public domain notice, that is Alexei's, right?
Yes.
Do you intend your modified version to also be in the public domain? (If we end up doing any major changes to the file, I'd prefer to license the Nettle version as LGPL, but if changes are minor, keeping it public domain is fine with me).
I claim no copyright in my changes (they are minor), so the original license applies. There is no problem with me to change it to LGPL though.
The rhash license appear to be somewhat different (see http://rhash.anz.ru/license.php), and the sourceforge page says it's using the MIT license (see http://sourceforge.net/projects/rhash/).
Do you want me to contact him for clarification? However, I think that the file's license overrides the library license.
+/**
- Calculate a lookup table from S-Boxes.
- A substitution table is used to speed up hash calculation.
- @param out pointer to the lookup table to fill
- @param src pointer to eight S-Boxes to fill the table from
- */
+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? They are already in gosthash94-tables.c. Is there any advantage in generating them during build time? I was thinking to even remove the fill_gost94_sbox() function. The sboxes are comparable in size to the blowfish sboxes. What do you think?
+void +gost94_init2 (gost94_ctx * ctx, unsigned int flag) +{
- memset (ctx, 0, sizeof (gost94_ctx));
- ctx->flag = flag;
- if (ctx->flag & GOST_FLAG_CRYPTOPRO)
ctx->sbox = (uint32_t*)gost94_sbox_cryptpro;- else
ctx->sbox = (uint32_t*)gost94_sbox;+}
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.
I don't quite like having to put an sbox pointer into the context struct, but maybe there's a good reason?
If the sboxes are like now in a constant array there are no issues, with memcpy of contexts (if this is your concern).
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.
+#undef GENERATE_GOST_LOOKUP_TABLE
I don't think GENERATE_GOST_LOOKUP_TABLE belongs in the header file.
Why would it be better? The header uses this definition.
btw. I've renamed the algorithm to gosthash94, to allow for a future gost encryption algorithm.
+/* algorithm context */ +typedef struct gost94_ctx +{
- uint32_t hash[8]; /* algorithm 256-bit state */
- uint32_t sum[8]; /* sum of processed message blocks */
- uint8_t message[GOST94_DATA_SIZE]; /* 256-bit buffer for leftovers */
- uint64_t length; /* number of processed bytes */
- uint32_t *sbox;
- unsigned flag; /* flag, type of sbox to use */
The flag is set but unused, as far as I see.
Removed.
regards, Nikos