Long delay creating DH key pair about mirc_fish_10 HOT 5 CLOSED

How often are you exchanging keys so that this is a problem? More key exchanges can even make communication less secure than more (unless you have some external means of confirming the other side's identity).

But indeed the DH_check call is not well-placed. Thanks for your input already, I'll see if I can come up with a solution that uses DH_check_params (which should be much quicker) and/or performs a lazy check on startup or on first use. I'll also double check the flow around DH_compute_key.

from mirc_fish_10.

with auto key exchange, it would introduce a noticeable freeze while typing, mouse clicking, etc.

A global memory variable within the DLL could be initialized to zero, and could be flipped to 1 after running DH_Check, so checking the global var would allow the dll to do the DH_check only 1 time, or do it zero times if they never generated a key pair.

I don't think DH_check_params is a good substitute. If I'm reading the source correctly, it looks like all it does is verify:

g >= 2
g < (p-1)
p is odd
p > 1
p >= minimum bits 512
p <= max bits 65536

If I'm reading that correctly, DH_check_params would validate approximately half of random 'p' values since they were odd numbers, so isn't worth the effort.

I guess if the older semi-fast check isn't part of OpenSSL anymore, it either needs to keep using the slower DH_check or not bother checking. The former check was reasonably fast and still managed to do reasonable validation of 'p'. Under the old dll, it verified that 'p' was prime, as well as q=(p-1)/2 being prime, and that 'p modulo 24 was 11. What I don't know is how strong were the verify that p and q were prime.

from mirc_fish_10.

I'm just going to fire up a background thread for initialization ON STARTUP with the appropriate synchronization primitives.

from mirc_fish_10.

That sounds like a great solution that I didn't think of, and would work as long as someone didn't manually unload FiSH with "/dll -u fish_10.dll" then try to immediately call DH1080_Generate causing it to reload the dll, which there should be no legit reason for doing.

from mirc_fish_10.

New version released today, including a fix for this issue, please test, and open a new issue if required 😝

from mirc_fish_10.