Hi koenv,
The change was implemented in 8.0 Beta 1, and is related to the news surrounding the
Logjam vulnerability. The Logjam vulnerability in and of itself is not applicable to SecureCRT (since SecureCRT is not an SSL v3 client), but information from the authors who conducted the associated research indicate that 1024-bit primes are subject to brute-force nation-state cracking and actually mention SSH servers being potentially susceptible (those which enable / use / allow diffie-hellman key exchange with 1024-bit or lesser primes).
See the following articles for more information about the weakness of diffie-hellman, 1024-bit primes, etc.:
https://www.schneier.com/blog/archiv...gjam_and_.html
https://weakdh.org (particularly point #2 which talks of nation-states being able to break a 1024-bit prime).
Because of this new research, diffie-hellman can largely be considered as weak/deprecated much the same way as 3DES and MD5 are now considered weak/deprecated.
For the security-minded professional, diffie-hellman should be left disabled, and only enabled in those rare circumstances where the device to which you are connecting does not support anything newer/stronger/better.
Note: "diffie-hellman" is not the same as "diffie-hellman-group14" (uses the Oakley Group 14 2048-bit prime -- see
RFC 3526), which is considered to be more secure than diffie-hellman (uses the Oakley group 2 1024-bit prime -- see
RFC 2409).
Then there is "diffie-hellman-group" key exchange in which the client and the server negotiate regarding the size of primes that will be used/allowed during key exchange (see
RFC 4419). This "diffie-hellman-group" key exchange method is also considered more secure
AS LONG AS the list of primes configured to be used on the server side are > 1024-bits in size. This new information is also why as of version 4.1 of our VShell SSH2 server product, the list of primes available for diffie-hellman-group key exchange no longer include any that are < 1536-bits in size.