Cryptography: handle FFDH deprecation

[gpotter2]

Some functions of cryptography are getting deprecated. See pyca/cryptography#15171 for more infos.

This is to track our progress on that issue.

[devmaiter]

Hi! I'd be glad to pick this up if it's still available — align the annotation with the runtime behavior and check that nothing relies on the current typing. Let me know!

[gpotter2]

Hi & thanks for your interest ! I don't think that this is a great starter for newcomers :P I'm pretty sure that we'll have to try to convince the cryptography folks to move this to decrepit rather than removing it.

[alex]

So, there's two things here: one is the ultimate timeline for removal, which is very much up in the air.

The other is having the scapy tests pass while we're issuing a warning. As you can see on pyca/cryptography#15171, just emitting a warning causes scapy test failures, and we'd love to get that fixed so we can start warning :-)

[gpotter2]

Hi alex, sorry for the previous wording.

It would be easier for us to know whether this will end up in decrepit or not. With previous decrepit stuff, importing from the normal module would raise a warning, but importing from decrepit wouldn't.

• If FFDH does end up in decrepit it would be easier for us if Deprecate Diffie-Hellman over finite fields (FFDH) pyca/cryptography#15171 already included the decrepit part (without warnings) so that we could just try/catch the imports.
• If it doesn't, then we can catch those warnings in the meantime, while we think about what support we want to provide.

For context, FFDH is used a lot in TLS (even TLS1.3), and we try to provide support for all versions (dating as far as SSLv2) for testing/debug purposes (that's just what Scapy is really).

[alex]

We don't currently have a plan to move it to decrepit, no. The current plan is to deprecate in-place for an indefinite period of time. (cc @reaperhulk)

The world is basically going to have to burn down all FFDH usage in the next few years (in favor of PQ algorithms), so the usage should go way down :-) Fortunately, FFDH is also simple enough that perf isn't a concern, pow() is sufficient.

(CC @reaperhulk)