Nikos Mavrogiannopoulos <[email protected]> writes: > In master (unsigned int) was replaced with (size_t), that allows for > even larger sizes to be input to encryption and decryption functions. > However, the usage of TMP_ALLOC to make a copy of the input data > (e.g., in ctr.c) contradicts that goal.
The intention is that TMP_ALLOC should only ever be used for small allocations. And each use must specify a maximum size. If you see any TMP_ALLOC with a potentially large size, that is a bug. (In case anyone else here is also hacking gmp, I should point out that gmp's TMP_ALLOC is different)) In ctr.c, the max size is 128 bytes (NBLOCKS * NETTLE_MAX_CIPHER_BLOCK_SIZE). I see no problem there, except that an assert (block_size <= NETTLE_MAX_CIPHER_BLOCK_SIZE); might be appropriate. > I think there can be an easy modification of TMP_ALLOC to use malloc > for larger than 128 (or any other fixed number), and alloca otherwise. As far as possible, I think we should avoid large allocations. So I don't think such a change is needed. 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
