[SSH] Added key size selection

[axmanalad]

This implementation allows to select the key size of the generated key ranging from 2048-4096 bits, which is using a Spinner to increment by 1024 bits. (DSA is limited to 3072 bits)

Refer to #1464

[github-actions]

Test Results

 1 755 files  ±0   1 755 suites  ±0   1h 28m 32s ⏱️ - 12m 41s
 4 170 tests ±0   4 148 ✅ ±0   22 💤 ±0  0 ❌ ±0 
13 107 runs  ±0  12 943 ✅ ±0  164 💤 ±0  0 ❌ ±0 

Results for commit 06c9fe9. ± Comparison against base commit d5c652b.

♻️ This comment has been updated with latest results.

[HannesWell]

Thank you for this follow-up. Nice work, it works well.
I just have a few remarks below.

In general what do you think about setting the initial value to the recommended size of 4kBi for RSA and 3kBi for DSA and just allow lowering the value?
Are higher values possible for RSA too? If yes, I think we should also make that possible.

Additionally please make sure that you have formatted all new lines according to the formatter settings (unfortunately the existing code does not adhere to them). E.g. there should be a space before and after a equal-sign.

[axmanalad]

In general what do you think about setting the initial value to the recommended size of 4kBi for RSA and 3kBi for DSA and just allow lowering the value?

I think this is a good idea as it initially sets it to the more secured key size than 2048 bits for developers to acknowledge. I changed the initial value to 4096 bits.

Additionally please make sure that you have formatted all new lines according to the formatter settings (unfortunately the existing code does not adhere to them). E.g. there should be a space before and after a equal-sign.

I have fixed the formatting. Thank you for clarification.

Are higher values possible for RSA too? If yes, I think we should also make that possible.

Higher values for RSA are possible. The current RSA algorithm does not seem to have a limit for the max key size it can generate. However, the main drawbacks with generating larger RSA key lengths include CPU overhead and performance issues. As you generate a larger key length, CPU runtime increases dramatically. A high-end computer could easily generate larger keys, but I would not recommend it for low-end computers.

Because of the overhead and performance, it is best to recommend using an ECC encryption for keys larger than 4096 bits since it provides an equivalent level of encryption strength as RSA with smaller key sizes and faster performance. For example, an ECC key size of 512 bits is equivalent to an RSA key size of 15360 bits. I am not sure how implementing ECC would work but it is only a thought I think would improve performance in generating keys.

I changed the max RSA key size you can generate to 15360 bits as it is equivalent to 256 security bits (really strong in security encryption); generally, higher than 15360 bits is not recommended for the sake of runtime.

[HannesWell]

Thanks for the update and sorry for the deplayed reply.
I just have a few minor style remarks below.
Technically this is fine. 👍🏽

But we are currently in the quiet-period before the December release and have to await the start of the next development cycle, which should start in one to two weeks, before this can be submitted. But in the meantime we can make it ready.

Because of the overhead and performance, it is best to recommend using an ECC encryption for keys larger than 4096 bits since it provides an equivalent level of encryption strength as RSA with smaller key sizes and faster performance. For example, an ECC key size of 512 bits is equivalent to an RSA key size of 15360 bits. I am not sure how implementing ECC would work but it is only a thought I think would improve performance in generating keys.

It would be great if we could also generated more modern keys and if you are interested in looking into it, you are more than welcome.
I'm not sure, but I fear that the currently used library is not capable of these newer algorithms.
In fact we actually would like to replace JSCH with something that's maintained better and more up-to-date, but havn't done it yet due to a lack of known simple replacements, see

• Replace or remove org.eclipse.jsch plugins? #958

But if you are interested in that please don't hesitate to look into it. :)

[axmanalad]

No worries, it is understandable. I reformatted the variables as requested.

It would be great if we could also generated more modern keys and if you are interested in looking into it, you are more than welcome. I'm not sure, but I fear that the currently used library is not capable of these newer algorithms. In fact we actually would like to replace JSCH with something that's maintained better and more up-to-date, but havn't done it yet due to a lack of known simple replacements, see

• Replace or remove org.eclipse.jsch plugins? #958

But if you are interested in that please don't hesitate to look into it. :)

While looking in the #958, I believe replacing the JSch library is a major change to be made. I lack the knowledge to knowing how to make these replacements however. In the meantime, I looked deeper into the codebase to find that there exists an ECC algorithm in the JSch library known as ECDSA before the library became outdated. This is a type of ECC algorithm that does exactly what I previously stated and is found within "com.jcraft.jsch.KeyPairECDSA". Maybe after this PR, I can make a third contribution to add the feature of generating ECDSA keys in a new PR, which is why I added a "TODO" comment on Line 509.

[HannesWell]

Sorry, I somehow missed the notification about your latest update, will look into it as soon as possible.

It would be great if we could also generated more modern keys and if you are interested in looking into it, you are more than welcome. I'm not sure, but I fear that the currently used library is not capable of these newer algorithms. In fact we actually would like to replace JSCH with something that's maintained better and more up-to-date, but havn't done it yet due to a lack of known simple replacements, see

• Replace or remove org.eclipse.jsch plugins? #958

But if you are interested in that please don't hesitate to look into it. :)

While looking in the #958, I believe replacing the JSch library is a major change to be made. I lack the knowledge to knowing how to make these replacements however. In the meantime, I looked deeper into the codebase to find that there exists an ECC algorithm in the JSch library known as ECDSA before the library became outdated. This is a type of ECC algorithm that does exactly what I previously stated and is found within "com.jcraft.jsch.KeyPairECDSA". Maybe after this PR, I can make a third contribution to add the feature of generating ECDSA keys in a new PR, which is why I added a "TODO" comment on Line 509.

That would be very nice. But we should be cautious and should check how well that implementation works. Having a flawed implementation of a per-se save algorithm would pretend false security, which would be really bad.

[HannesWell]

This looks perfectly fine now.
Thanks for the update and sorry for the delayed reply. I lost track of this during the hectic rush before Christmas.

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

team/bundles/org.eclipse.jsch.ui/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From fc820e77534910a8a44c1d3e74bcdc00d57017f3 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Sun, 29 Dec 2024 23:29:49 +0000
Subject: [PATCH] Version bump(s) for 4.35 stream


diff --git a/team/bundles/org.eclipse.jsch.ui/META-INF/MANIFEST.MF b/team/bundles/org.eclipse.jsch.ui/META-INF/MANIFEST.MF
index c5bccee193..94db42dfc6 100644
--- a/team/bundles/org.eclipse.jsch.ui/META-INF/MANIFEST.MF
+++ b/team/bundles/org.eclipse.jsch.ui/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %pluginName
 Bundle-SymbolicName: org.eclipse.jsch.ui;singleton:=true
-Bundle-Version: 1.5.500.qualifier
+Bundle-Version: 1.5.600.qualifier
 Bundle-Activator: org.eclipse.jsch.internal.ui.JSchUIPlugin
 Bundle-Vendor: %providerName
 Bundle-Localization: plugin
-- 
2.47.1

Further information are available in Common Build Issues - Missing version increments.