pycrypto ARC2.new rejects effective_keylen parameter

[Peter]

A bug report for pyCrypto 2.6.1.

When I issue:
      arc2 = ARC2.new(self.key, mode=ARC2.MODE_CBC, effective_keylen=8*len(self.key))
to decrypt or encrypt, the system complains that:
 'effective_keylen' is an invalid keyword argument for this function

It doesn't happen with pyCrypto 2.5.0

I tried to look in the code.
There are three ARC2 files.
ARC2.py, ARC2.so, _ARC2.so

Looking at the comments for the ARC2.py module, I see that it does expect the effective_keylen,
and if I rename the ARC2.so, so for the system to use ARC2.py, it doesn't complain at this stage (it complains somewhere else - about a wrong IV which is probably related to the _ARC2.so module). So the ARC2.so seems to be inconsistent with ARC2.py + _ARC2.so. It seems like a bug (the source and library inconsistency) - at least the comment is inconsistent with the behavior, and I couldn't find a proper documentation for that.

[Legrandin (gooksankoo)]

I can't exactly reproduce this. What is self.key in your example?

One odd thing that strikes me is that you don't pass an IV parameter, but that is absolutely required for CBC mode.

[Peter (prenkel)]

Hi,

Thank you.
According to the documentation, this parameter is not a required one. See
the last line in the highlighted block.
Supplying all zeroes for the IV, solves the issue in 2.6.1. The 2.5 worked
without supplying these parameters.
Can you may be update the documentation in
https://www.dlitz.net/software/pycrypto/api/current/ (or make it default)?

   -

   *IV* (byte string) - The initialization vector to use for encryption or
   decryption.

   It is ignored for
MODE_ECB<https://www.dlitz.net/software/pycrypto/api/current/Crypto.Cipher.ARC2-module.html#MODE_ECB>
    and MODE_CTR<https://www.dlitz.net/software/pycrypto/api/current/Crypto.Cipher.ARC2-module.html#MODE_CTR>
   .

   For MODE_OPENPGP<https://www.dlitz.net/software/pycrypto/api/current/Crypto.Cipher.ARC2-module.html#MODE_OPENPGP>,
   IV must be block_size<https://www.dlitz.net/software/pycrypto/api/current/Crypto.Cipher.ARC2-module.html#block_size>
bytes
   long for encryption and
block_size<https://www.dlitz.net/software/pycrypto/api/current/Crypto.Cipher.ARC2-module.html#block_size>
+2
   bytes for decryption (in the latter case, it is actually the *encrypted* IV
   which was prefixed to the ciphertext). It is mandatory.

   For all other modes, it must be
block_size<https://www.dlitz.net/software/pycrypto/api/current/Crypto.Cipher.ARC2-module.html#block_size>
bytes
   longs. It is optional and when not present it will be given a default value
   of all zeroes.

Thank you again.

Peter.

On Fri, Nov 29, 2013 at 10:39 AM, Legrandin <email address hidden>wrote:

> I can't exactly reproduce this. What is self.key in your example?
>
> One odd thing that strikes me is that you don't pass an IV parameter,
> but that is absolutely required for CBC mode.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1255560
>
> Title:
> pycrypto ARC2.new rejects effective_keylen parameter
>
> Status in Python Cryptography Toolkit:
> New
>
> Bug description:
> A bug report for pyCrypto 2.6.1.
>
> When I issue:
> arc2 = ARC2.new(self.key, mode=ARC2.MODE_CBC,
> effective_keylen=8*len(self.key))
> to decrypt or encrypt, the system complains that:
> 'effective_keylen' is an invalid keyword argument for this function
>
> It doesn't happen with pyCrypto 2.5.0
>
> I tried to look in the code.
> There are three ARC2 files.
> ARC2.py, ARC2.so, _ARC2.so
>
>
> Looking at the comments for the ARC2.py module, I see that it does
> expect the effective_keylen,
> and if I rename the ARC2.so, so for the system to use ARC2.py, it
> doesn't complain at this stage (it complains somewhere else - about a wrong
> IV which is probably related to the _ARC2.so module). So the ARC2.so seems
> to be inconsistent with ARC2.py + _ARC2.so. It seems like a bug (the source
> and library inconsistency) - at least the comment is inconsistent with the
> behavior, and I couldn't find a proper documentation for that.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/pycrypto/+bug/1255560/+subscriptions
>

[Richard Mitchell (mitchellrj)]

There should not be any "ARC2.so" in 2.6.1, only "_ARC2.so" and "ARC2.py". Do you still get the error in a fresh virtualenv with a new install of pycrypto?