Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reintroduce Alleged IDEA #76

Open
wants to merge 7 commits into
base: master
from

Conversation

Projects
None yet
4 participants
@mitchellrj
Copy link
Contributor

commented Apr 28, 2014

All the patents on IDEA have now expired. The trademark on the name remains, hence "Alleged IDEA". This pull request is based on the original IDEA code from dlitz/pycrypto@v2.0.1 which was removed in dlitz/pycrypto@v2.1.0alpha1.

All tests pass as expected.

@dlitz

This comment has been minimized.

Copy link
Owner

commented May 3, 2014

Thanks for taking the time to put together this patch, but do we really want to re-introduce a 64-bit block cipher into PyCrypto in 2014, when AFAIK everyone downstream has done just fine without it?

@mouse07410

This comment has been minimized.

Copy link

commented May 4, 2014

On May 3, 2014, at 4:32 , Dwayne Litzenberger notifications@github.com wrote:

Thanks for taking the time to put together this patch, but do we really want to re-introduce a 64-bit block cipher into PyCrypto in 2014, when AFAIK everyone downstream has done just fine without it?

IMHO, no reason not to. Not every application (just the majority of them :) needs a 128-bit block cipher.

@mitchellrj

This comment has been minimized.

Copy link
Contributor Author

commented May 5, 2014

It's a small gain for an even smaller amount of effort.

Any google search for Python IDEA still yields results for PyCrypto only
and anyone searching for it (as I did) will currently be disappointed.
People have done fine without it because they haven't had any alternative
and have had to find a different approach.

I am somewhat biased, as I do have a genuine use-case for it.

On 4 May 2014 13:35, Mouse notifications@github.com wrote:

On May 3, 2014, at 4:32 , Dwayne Litzenberger notifications@github.com
wrote:

Thanks for taking the time to put together this patch, but do we really
want to re-introduce a 64-bit block cipher into PyCrypto in 2014, when
AFAIK everyone downstream has done just fine without it?

IMHO, no reason not to. Not every application (just the majority of them
:) needs a 128-bit block cipher.


Reply to this email directly or view it on GitHubhttps://github.com//pull/76#issuecomment-42131944
.

@mouse07410

This comment has been minimized.

Copy link

commented May 6, 2014

Another reason - most of the decent crypto libraries support IDEA. Why should PyCrypto be an unpleasant exception?

On May 5, 2014, at 19:28 , Richard Mitchell notifications@github.com wrote:

It's a small gain for an even smaller amount of effort.

Any google search for Python IDEA still yields results for PyCrypto only
and anyone searching for it (as I did) will currently be disappointed.
People have done fine without it because they haven't had any alternative
and have had to find a different approach.

I am somewhat biased, as I do have a genuine use-case for it.

On 4 May 2014 13:35, Mouse notifications@github.com wrote:

On May 3, 2014, at 4:32 , Dwayne Litzenberger notifications@github.com
wrote:

Thanks for taking the time to put together this patch, but do we really
want to re-introduce a 64-bit block cipher into PyCrypto in 2014, when
AFAIK everyone downstream has done just fine without it?

IMHO, no reason not to. Not every application (just the majority of them
:) needs a 128-bit block cipher.


Reply to this email directly or view it on GitHubhttps://github.com//pull/76#issuecomment-42131944
.


Reply to this email directly or view it on GitHub.

@Legrandin

This comment has been minimized.

Copy link
Contributor

commented May 6, 2014

most of the decent crypto libraries support IDEA. Why should PyCrypto be an unpleasant exception?

Most crypto libraries have been around for a long time, and IDEA is included because it made sort of sense at that time, when AES did not exist.
For instance, PolarSSL is moderately recent, and it has no IDEA support. RFC5469 has also deprecated IDEA in TLS.

@mitchellrj , what is exactly the genuine use case for IDEA (if you can disclose it)?

@mitchellrj

This comment has been minimized.

Copy link
Contributor Author

commented May 6, 2014

I'm working on a pure-python OpenPGP implementation for which IDEA is one of the symmetric algorithms used http://github.com/mitchellrj/python-pgp

I have written my own wrappers around existing Twofish and Camellia libraries for that project to add PyCrypto support, but there was no alternative IDEA library. This pull request seemed the most sane and reasonable way to support IDEA. I'm actually suprised it met any ideological resistance.

@Legrandin

This comment has been minimized.

Copy link
Contributor

commented May 6, 2014

I find the PR sane and reasonable. The concern here is that adding a cipher implies more maintananance and more testing to do, and the only identifiable pay-off for IDEA is enabling people to access some 15 year old PGP files or emails they found on a floppy (the OpenPGP RFC is pretty clear in indicating that IDEA should only be supported by applications that want to be compatible to PGP 2.6.x - which is 20 years old. IDEA should not be used to create new files). Or is IDEA more used in practice than that (E.g. what does PGP Desktop now Symantec use by default)?

@@ -465,6 +466,9 @@ not currently feasible, and it has been estimated to be useful until 2030.
Bruce Schneier endorses DES3 for its security because of the decades of
study applied against it. It is, however, slow.

There are no publicly known attacks against AIDEA (3050 K/sec), and
it's been around long enough to have been examined.

This comment has been minimized.

Copy link
@dlitz

dlitz Jun 9, 2014

Owner

Replace with something like this:

IDEA encryption is not supported.  Like all 64-bit block ciphers, IDEA
encryption has a relatively high likelihood of leaking information due to its
short block size. (See McGrew, "Impossible plaintext cryptanalysis and
probable-plaintext collision attacks of 64-bit block cipher modes"
https://eprint.iacr.org/2012/623)  Limited support for IDEA decryption exists
to allow reading messages encrypted with PGP 2.6.x (using third-party tools).

This comment has been minimized.

Copy link
@mouse07410

mouse07410 Jun 9, 2014

Quoting Dwayne Litzenberger notifications@github.com:

+There are no publicly known attacks against AIDEA (3050 K/sec), and
+it's been around long enough to have been examined.
+

This is misleading. Yes, IDEA has been examined, and it's known to
be vulnerable against plaintext-recovery attacks, which are feasible
after an expected 2^32 blocks due to its 64-bit block size. See
https://eprint.iacr.org/2012/623

That is a very good reference!

Still, this birthday paradox-based attack applies to all the block
ciphers. It
is hardly a weakness specific to IDEA. Naturally, for the block ciphers with
64-bit block, the expected number of blocks is 2^32, while for the
ciphers with
128-bit block it is 2^64. Still, there are reasons for people to use ciphers
with a shorter block length (consider the recent release of SIMON and SPECK
algorithms). And the excellent paper you cited explicitly states that 64-bit
block ciphers are fine in case of "...very low data rates and keys are changed
often." I see no reason to restrict IDEA to decrypting old messages only.

If I could have my way, the original RIJNDAEL would get a few more rounds
(anything between 2 and 4 would be find) and become the new standard, with a
option of 256-bit block (rather than cutting off 256-bit block option and
leaving the # of rounds as is). But in practice we may need blocks
shorter than
128 bits.

This section is essentially complete, and the software interface will
almost certainly not change in an incompatible way in the future; all
that remains to be done is to fix any bugs that show up. If you
RIPEMD160), and various encryption algorithms (AES, DES, AIDEA, RSA,

This comment has been minimized.

Copy link
@dlitz

dlitz Jun 9, 2014

Owner

There's no need to mention IDEA here. It's deprecated anyway.

@@ -0,0 +1,130 @@
# -*- coding: utf-8 -*-

This comment has been minimized.

Copy link
@dlitz

dlitz Jun 9, 2014

Owner

Please revert this (and all other instances of "AIDEA") to the original name, "IDEA". "Alleged-RC4" came from the fact that RC4 was originally a trade secret and became public via an anonymous email with source code. IDEA has no such colorful history, and this is the first time I've ever seen anyone refer to "Alleged IDEA".

Actually, it would be preferable to drop IDEA.py and just implement everything necessary in IDEA.c (this might require moving the MODE_OPENPGP implementation to block_template.c... that's fine with me; it shouldn't be too hard).

#define MODULE_NAME _AIDEA
#define BLOCK_SIZE 8
#define KEY_SIZE 16

This comment has been minimized.

Copy link
@dlitz

dlitz Jun 9, 2014

Owner

Please rebase onto https://github.com/dlitz/pycrypto/tree/select-modes, then define the HAS_MODE_* constant that's necessary to decrypt messages encrypted with PGP 2.x. Leave the others undefined.


#include "pycrypto_common.h"

#ifdef MS_WIN32

This comment has been minimized.

Copy link
@dlitz

dlitz Jun 9, 2014

Owner

Let's not add a dependency on the sockets library just for a byte-swap.

@dlitz

This comment has been minimized.

Copy link
Owner

commented Jun 9, 2014

See my in-line comments.

I'd normally close this as WONTFIX, but PGP 2.x is enough of a historical figure that I'm considering merging limited IDEA support that would allow decrypting old PGP 2.x messages---i.e. decryption-only, ECB mode, and whichever CFB mode PGP 2.x requires. If this can be done such that the code is basically maintenance-free and doesn't encourage people to start using IDEA, I'd consider merging it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.