Allow __init__ without iv?

[parke]

I'm creating an AES cipher instance that I will use repeatedly, calling .set_iv() before each encryption session.

Yet the tomcrypt.cipher.aes.init raises an error if I do not provide an iv.

The iv is not needed until encrypt time. Do you really want init to raise an error if no iv is provided? (Maybe you do.)

[mikeboers]

I do want it to raise the error.

While your use case is possible, my feeling from LibTomCrypt and my usage PyTomCrypt is that cipher objects are so light weight that they are used once and then discarded without holding on to them for long.

Since I feel that is the primary usage, and I don't want to have a missing IV signify a null IV. I would like to fail as close to the source of the lack of an IV as possible, which is the Cipher constructor.

Feel free to offer a dissenting opinion.

[parke]

It is your library, so as long as it is intentional, I understand.

I value readable code before all else, and I dislike assigning a value that will never (in my case) be used. (I will be encrypting many 20 byte plaintexts with the same key.)

If ciphers are used in a lightweight manner, as you suggest, then the creation and the use should be close together. In this case, why does it matter that the error traceback direct the programmer to the encrypt call, rather than the cipher creation?

I believe AES key scheduling/preparation takes significantly longer than setting the IV. I expect setting the IV is just a copy operation, whereas there is an actual procedure to follow to set up the key. But I could be wrong.

[mikeboers]

The key schedule merits investigation; you are definitely right there.

We do definitely need to error if an IV was never set, since I don't want someone to accidentally not do so. And, like you said, my described usage wouldn't put the error very far from the construction.

Hmm...

I'll take a deeper look tomorrow.

On 2013-11-13, at 10:17 PM, parke wrote:

It is your library, so as long as it is intentional, I understand.

I value readable code before all else, and I dislike assigning a value that will never (in my case) be used. (I will be encrypting many 20 byte plaintexts with the same key.)

If ciphers are used in a lightweight manner, as you suggest, then the creation and the use should be close together. In this case, why does it matter that the error traceback direct the programmer to the encrypt call, rather than the cipher creation?

I believe AES key scheduling/preparation takes significantly longer than setting the IV. I expect setting the IV is just a copy operation, whereas there is an actual procedure to follow to set up the key. But I could be wrong.

— Reply to this email directly or view it on GitHub.