Cryptography: Support for AES-IGE mode of operation

Created on 23 Aug 2017  路  10Comments  路  Source: pyca/cryptography

I know it's only used for Telegram, but it would be nice to have it directly in this Python module.

All 10 comments

We are unlikely to add something which such limited usage, particular Telegram, given it's poor cryptographic history.

In case anyone is bothered here's a C implementation for it I wrote myself for the tiny AES library.

Is there a case to be made in adding IGE for the sake of harm reduction? Given issues like this one: https://github.com/pyrogram/tgcrypto/issues/6

I'm not sure how much maintenance burden this creates but I'll be looking into that soon.

It wouldn鈥檛 be a maintenance burden, but any proposal for adding it needs to come up with a way to convey that it is a bad mode that shouldn鈥檛 exist and is provided solely for compatibility purposes.

Good documentation, perhaps? An "important" or "note" block maybe with with bold words "It is not encouraged to use X unless you know what you're doing" or "You shouldn't use X and favour Y".

We do that in some other places and it's as good as we know how to do right now. I would review an IGE patch at this point as I believe that while it's an awful mode we should support the things needed to interoperate with major projects (Even if those major projects made some very, very weird choices). Ignoring it is just encouraging people to look in more dangerous locations/do more dangerous things.

To be clear, here's what is needed to land IGE:

  • [ ] Test vectors (https://www.links.org/files/openssl-ige.pdf) converted into NIST compatible form (see: https://github.com/pyca/cryptography/blob/cd4de3ce6dc2a0dd4171b869e187857e4125853b/vectors/cryptography_vectors/ciphers/AES/CBC/CBCGFSbox128.rsp) and information about them added to test-vectors.rst. This should be the first PR.
  • [ ] The actual implementation (which is actually pretty simple, follow the form of CBC)
  • [ ] Tests using those vectors (see test_aes.py)
  • [ ] Docs describing it and noting that it is bad and provided for compatibility purposes only

So, may we reopen the issue to keep track of the progress?

Looking at this OpenSSL has chosen to not even expose IGE mode at the EVP layer. This means supporting it requires a different codepath than every other cipher/mode we have. That is a significant maintenance burden so I think this may not be practical.

Okay, maintaining a separate set of bindings and dedicated code just for a single (bad) cipher mode is not something we're willing to do so the answer remains no on adding support.

Yikes! Didn't know it was this annoying to support. Thanks for humoring the idea, at least.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ShaneHarvey picture ShaneHarvey  路  20Comments

freedge picture freedge  路  22Comments

TrollNation picture TrollNation  路  20Comments

alex picture alex  路  28Comments

ctismer picture ctismer  路  29Comments