I wrote: > Now that the more ciphers in nettle work with fix key size, maybe it > would be a good idea to drop the length argument also from the > nettle_set_key_func typedef?
Simon Josefsson <si...@josefsson.org> writes: > How would you then handle ciphers that accepts arbitrary key sizes? You should call the algorithm-specific functions which accepts variable key size, e.g., cast128_set_key. But you will no longer be able to pass arbitrary key size via the function pointers nettle_cast128.set_*_key, which will then be a wrapper function specifying a fix key size. So this change affects the interface via the structs in nettle-meta.h. And any application code which use the nettle_crypt_func typedef for other purposes. Direct use via algorithm specific function keeps following the same principle: Algorithms with variable key size have a _set_key function with a length parameter. Algorithms with a fix key size take no length parameter. I think this makes sense, because struct nettle_cipher contains no information about possible key sizes, only a single value. So if other key sizes are possible, there's no way to tell from looking at the struct nettle_cipher instance that represents the algorithm. Except by examining the name field... For aes, aes_set_*_key (which is kept for backwards compatibility) accepts a length parameter, but the new and recommended functions, aes128_set_*_key, aes192_set_*_key, aes256_set_*_key, do not. In effect, the new interface treats aes128, aes192 and aes256 as distinct algorithms, with any similarities being an implementation detail. And I'm now considering doing the same with other aes-style algorithms. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ nettle-bugs mailing list nettle-bugs@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
