Stephen Sprunk wrote:
> If we document that *num must always be zero on first use (not sure
> how I can assert() that), is there any bug that needs fixing?
Yes, the sample code I included in a previous post demonstrates the bug
despite num being zero on first use.
Matt
On Tuesday 30 July 2002 02:54 pm, Richard Levitte - VMS Whacker wrote:
> How could num (or n, inside AES_ctr128_encrypt() ever have a value
> that isn't between 0 (included) and AES_BLOCK_SIZE (excluded), unless
> you do something stupid with num between calls? Make note of the
> following state
I think there's a bug in the AES counter mode implementation: if you pass a
non-zero counter offset to AES_ctr128_encrypt() (through the "num" argument),
this function will access unitialized data in "tmp".
I'm not sure if this function is intended to provide stream-like services, but
if it is
