tls/crypto /cipher_block.py relies on cryptography internal details that are going away eventually

[alex]

tls/crypto /cipher_block.py relies on cryptography internal details that are going away eventually

[gpotter2]

Thanks a lot for the notice, that's greatly appreciated.

To give some context, I was also planning to use those two functions in an upcoming PR (#4214).

Because we are a networking library, and network is old, we have some use cases where we want to be able to use and access old and obsolete cryptography algorithms that are still used in the real world in legacy applications. Most of those are still present in OpenSSL but not exported/accessible by cryptography, which is why we were using the already pretty great internal cryptography bindings. Do you know if it will still be possible to achieve a similar result after the change?

As an example, DES-CBC, which is of course completely obsolete, is still supported by MIT Kerberos servers, Heimdal (in samba or without) (and Windows) and it is therefore currently still present in OpenSSL (through legacy providers, if not by default). It is useful for us to have access to it, for the sake of testing legacy products or servers and/or for offensive purposes, etc.

I understand cryptography is aiming not to spread the usage of those legacy algorithms, but it would be really nice for our use case if there was some sort of undocumented way to still use cryptography in those use cases. Our alternatives are not great: in addition of using cryptography for most usages, to support those crappy legacy algorithms we would have to either use PyCryptodome (which is in a terrible state compared to cryptography), other OpenSSL bindings (which is far more annoying, and a bit too bad considering the work already put into cryptography's ones) or pack a custom Python implementation of those algorithms (which we already do for MD4 for instance, and is by far the worse option).

Sorry for the long post.

[alex]

In the specific case of DES, you can do this with cryptography using TripleDES -- TripleDES behaves the same as single DES for the case of a small key.

For the case here of RC2, I think we'd be willing to add a module for "super bad legacy stuff you should never use" that contains it.

Are there other cases we should consider?

[reaperhulk]

The decrepit module probably is where we'd eventually move the ciphers we currently have marked as deprecated (CAST5, IDEA, SEED, et al).

[gpotter2]

I think we'd be willing to add a module for "super bad legacy stuff you should never use" that contains it.

That would work great in our case, thanks a lot. I don't currently have any other case in mind, but having a "bad legacy module" would allow us to PR "easily" if we ever get the case, which sounds good.

The decrepit module probably is where we'd eventually move the ciphers we currently have marked as deprecated

That's great to know, it would also work great for us, as long as they remain somewhere.

In the specific case of DES, you can do this with cryptography using TripleDES

I for some reason thought TripleDES would enforce a 112/168 key length, but it indeed appears 56 is also usable. Tested it and it works great, thanks a lot for the tip.

[reaperhulk]

@gpotter2 I've been looking at this a bit more and RC2 is...quite an algorithm. It looks like you only currently implement/test against RC2-128, although you have an unused RC2_40_CBC class. Would it be enough if we gave you RC2-128 only (no alternate key sizes, no effective key bits support), or do you want/need RC2-40 (or RC2-64 for that matter)? And, if you need those, do you need the concept of effective key bits? If so, can we constrain the set of allowable values to something more than the sum of all possible permutations?

[gpotter2]

Hi @reaperhulk. I believe that we only use RC2 in context of the TLS/SSL ciphers, in which case only the RC2-128 version is used. When the 40bits-key is used (in 'EXPORT' ciphers), it is first derived into 128 bits with a TLS-specific process (that varies depending on whether RC2 is used with SSLv2, SSLv3 or TLS 1.0) that we implement, so there's no need to add support for the per-RC2-spec effective key bits and/or variable lengths.

This class is poorly named, it would have been much more obvious with its actual per-spec name: SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5

[reaperhulk]

Okay, then I think we'll land something that enables RC2-128-CBC only and then I'll send a PR that tries to import from the new namespace and falls back to your current patch method for older versions of cryptography 😄

[gpotter2]

Sounds great, thanks a lot ! If you need help with the PR please let me know.