Nikos Mavrogiannopoulos <[email protected]> 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 -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
