-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
tls/crypto /cipher_block.py relies on cryptography internal details that are going away eventually #4237
Comments
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. |
In the specific case of DES, you can do this with cryptography using 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? |
The |
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.
That's great to know, it would also work great for us, as long as they remain somewhere.
I for some reason thought |
@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? |
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: |
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 😄 |
Sounds great, thanks a lot ! If you need help with the PR please let me know. |
Brief description
scapy/scapy/layers/tls/crypto/cipher_block.py
Lines 207 to 222 in ae79fcb
This relies on
register_cipher_adapter
andGetCipherByName
which are not documented public APIs, and will be removed in pyca/cryptography#9859This PR is expected to land in May, so there's a bit of time to resolve.
If there's a missing API in cryptography, please let us know so we can find a proper solution.
Scapy version
main
Python version
all
Operating system
all
Additional environment information
No response
How to reproduce
n/a
Actual result
No response
Expected result
No response
Related resources
No response
The text was updated successfully, but these errors were encountered: