Regression : cannot use 3072-bit RSA key for authentication

Problem version : 5.17.1 (upgraded from 5.15.9)
Last working version : 5.15.9
OS Version : Windows 10 x64
UI mode : commander
Configuration :
remote server only uses AES for encryption, curve X25519 for key exchange.
private/public key pair is RSA, 3072-bit.
Steps to reproduce :
Open WinSCP, type in the IP and username, go to Advanced->ssh->authentication, select key file (ppk), click connect
Expected result :
Successful connection, as in 5.15.9 and below, with the exact same server and keypair.
Actual result :
Error message that winSCP cannot authenticate "cannot create key".

If WinSCP uses a PuTTY library, it is entirely possible that the bug comes from PuTTY, because we also had to downgrade it, as our keys were also causing problems on latest versions. However, this is only speculation.

Thanks in advance for any help/resolution , in the meantime we downgraded back to 5.15.9

Thanks for your report.
I cannot reproduce the problem. I can authenticate with 3072-bit RSA key without any problems.

Please attach a full session log file showing the problem (using the latest version of WinSCP).


How do you generate the key? Also can you generate a new key with the same parameters and post it here?

Hi, Thanks for taking the time to reply.

I tried doing so, however as you can see, the session log doesnt rally show why createkey failed, only that it did; I attached the same logs with 5.15.9.
I did put the logs at their maximum verbosity level.

We generate our keys via PHP/OpenSSH and then convert them to the PuTTY format all with a PHP script, because it's an automated remote process. I'm starting to wonder if indeed our keys are the problem. I attached a keypair I just generated with the same script for testing purposes.

Thanks again!

I indeed cannot even load your private key to PuTTYgen 0.73.
The latest development build of PuTTYgen does even hang while trying to load the key.

Yes, there seems to be a problem with padding the keys.

Your previous comment about the keys being the problem prompted me to try this :

Using an older PuTTY version that is able to load the keys, I loaded the server key, and saved it again using PuTTYGen ;
Then using a diff tool I saw the base64 private portion of the key is different ;
Now I'm using a hex editor to se the difference, it seems that there are two NULL bytes improperly placed in the file.
I'll update the topic if I'm able to resolve this.

Anyway thanks again for pointing me in the (hopefully) right direction!

After reviewing the script, I found the origin of the problem was the implementation (PHP side) of PuTTY's BinarySink_put_mp_ssh2_from_string (import.c) function, that adds a leading zero only in certain circumstances before a binary string, whereas our script was always adding it.

I can confirm after fixing that, that I can connect to the same server with the new key with WinSCP 5.17.1 and the latest PuTTY 0.73.

I don't know how to edit the topic subject, but this is resolved. (Why older PuTTY code did tolerate these keys remains a mystery though.)