[ssh] Generated Key are too weak

[laeubi]

If I go to Preferences > SSH > Key Management there is an option "Generate RSA key", this does (without an option to choose otherwise) generate a RSA-1024 key.

https://www.ssh.com/academy/ssh/keygen#choosing-an-algorithm-and-key-size says

A key size of at least 2048 bits is recommended for RSA; 4096 bits is better.

[ChelsyLan]

Our team (Chelsy Lan/Shawn Lin/Alexander Manalad) is working on this

[HannesWell]

Our team (Chelsy Lan/Shawn Lin/Alexander Manalad) is working on this

Great. You are some of the students from CodeDays, aren't you?

Much success on this task and don't hesitate to ask for help if you need any.

[ChelsyLan]

Yes we're students from CodeDays :)

[axmanalad]

Hi, I am part of the team who is currently working on this issue. We may have found a solution while we were checking out the files, but we want ask a few questions before committing to the solution.

• From our understanding with this issue, we need to improve the generated RSA key to provide a RSA-2048 instead of a RSA-1024 key?
• Is it a simple solution to where we can just change a value to generate a RSA-2048 key with no other files connected conflicting?
• Do we only need to improve the RSA key specifically and not the DSA key included?
• Should there be options to what kind of RSA key is generated? (ex. an option for 1024, 2048, 4096)

[Bananeweizen]

I'd like to add some more facts to the discussion: RSA-2048 will become unacceptable by NIST recommendations in 2030, requiring longer keys again latest at that time. However, the German BSI (Federal Office for Information Security) recommends at least 3000 bits since 2023, both for RSA and DSA. See https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile&v=7, chapters 5.3.1 and 5.3.2.

I don't mean to say that the German recommendation should affect everyone worldwide. But if there are multiple different recommendations, then taking the "most strict" requirement seems reasonable to me, given this is about cryptography.

I would therefore recommend to increase both DSA and RSA key sizes to 3072.

Should there be options to what kind of RSA key is generated?

No. Users don't know what effect that option has. Therefore they cannot make an informed choice. That's why we should take the decision for them, in a safe way.

[HannesWell]

Should there be options to what kind of RSA key is generated?

No. Users don't know what effect that option has. Therefore they cannot make an informed choice. That's why we should take the decision for them, in a safe way.

Agree on that, for that reason and to keep the UI and implementation simpler.

I would therefore recommend to increase both DSA and RSA key sizes to 3072.

I would even suggest to go one step further and use 4096 bit for both, if possible. Or is there a disadvantage in longer keys, besides greater key files?

• Is it a simple solution to where we can just change a value to generate a RSA-2048 key with no other files connected conflicting?

I haven't looked into the details on how it is implemented at the moment, but I assume that there is maybe one or maybe a few places where the 1024 is currently hard coded I it might be sufficient to change them to 4096. If there are multiple places I suggest to unify them to eventually have one constant for the key length in order to make further increases simpler in the future.

• Do we only need to improve the RSA key specifically and not the DSA key included?

Ideally both would be increased.

Btw. by pressing Alt+Shift+F1 you can activate the Plugin selection spy that shows you the class that implements the key management PreferencePage:

And the page https://github.com/eclipse-ide, should help you to set up an Eclipse workspace for the eclipse.platform repository.

[Bananeweizen]

I'm fine with 4K instead of 3K.

Or is there a disadvantage in longer keys

Besides (neglectible) disk storage increase, the main drawback is more compute resources necessary on the server. I'm not sure if the numbers still fit current CPUs, but stackoverflow basically says: 40 times more CPU when going from RSA 1K to 4K: https://stackoverflow.com/questions/1569544/performance-of-rsa-based-on-keysize

[laeubi]

At best of course the keysize can be selected by the user somehow.

[HannesWell]

At best of course the keysize can be selected by the user somehow.

@axmanalad, @ChelsyLan and the entire team, thank you for contributing a fix for this.
Would you be interested in a follow-up change to make the key-size configurable in the UI?
If yes, my suggestion would be to add a spin-button at that page that starts with the at least recommended 2048bit and can be incremented in 512 bit steps (or whatever reasonable steps are?) up unlit the upper limit the available algorithm supports.
The upper limit should then be investigated first.

[axmanalad]

At best of course the keysize can be selected by the user somehow.

Would you be interested in a follow-up change to make the key-size configurable in the UI? If yes, my suggestion would be to add a spin-button at that page that starts with the at least recommended 2048bit and can be incremented in 512 bit steps (or whatever reasonable steps are?) up unlit the upper limit the available algorithm supports. The upper limit should then be investigated first.

Yes, I am interested and willing to making a follow-up change by making the key-size configurable. I am not sure about my team but I will let them know about it.