summaryrefslogtreecommitdiff
path: root/src/usr.bin/nc
diff options
context:
space:
mode:
authortb <>2026-01-23 08:21:52 +0000
committertb <>2026-01-23 08:21:52 +0000
commite8699208c6c4338d425f0979a68ec6ea04009819 (patch)
treeef36c010a2e7aca4c89ff821d120c112cea99020 /src/usr.bin/nc
parentabaacba9756060fd447f010a2698e3150d3f5378 (diff)
downloadopenbsd-e8699208c6c4338d425f0979a68ec6ea04009819.tar.gz
openbsd-e8699208c6c4338d425f0979a68ec6ea04009819.tar.bz2
openbsd-e8699208c6c4338d425f0979a68ec6ea04009819.zip
Scapy special for DH_check()
The latest release of Scapy calls DH_check() on all the well-known Diffie-Hellman parameters for RFCs 2409, 3526, and 7919. It does this via pyca/cryptography at startup. Every single time. This is obviously very expensive, due to our 64 MR rounds (which are complete overkill now that we have BPSW). Instead of pondering the ideal number of rounds for BPSW with FFDH, simply skip the check if the parameter matches a well-known prime. These are known to be safe primes, so we can skip those super-expensive and pointless checks without any risk. This is only done for the public dh->p parameter. It could be further optimized, but with the follow-up commit adding the RFC 7919 primes this reduces the startup time to what it was before Scapy 2.7.0: < 1s. Reverting from 64 MR rounds to BN_check_primes rounds, we would still have ~8s startup time without this optimization, which isn't great for an interactive tool. Clearly, it's not entirely our fault, it's also Scapy and cryptography that do something ... suboptimal, but I think we're better off if DH_check() isn't a complete DoS vector. If you're using non-standard parameters with FFDH, you deserve it. We could consider adding a flag for non-well-known p and thus making DH_check() indicate failure for candidate primes larger than, say, 4k. https://github.com/pyca/cryptography/issues/14048 ok beck kenjiro
Diffstat (limited to 'src/usr.bin/nc')
0 files changed, 0 insertions, 0 deletions