[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 308 files   -   447  1 308 suites   - 447   1h 34m 54s ⏱️ - 9m 45s
 3 135 tests  - 1 035  3 113 ✅  - 1 035   22 💤 ±0  0 ❌ ±0 
10 002 runs   - 3 105  9 838 ✅  - 3 105  164 💤 ±0  0 ❌ ±0 

Results for commit bc15516. ± Comparison against base commit d9eeb60.

This pull request removes 1035 tests.

AllTests AllCheatSheetTests AllCompositeTests TestCheatSheetManagerEvents ‑ testNoHandler
AllTests AllCheatSheetTests AllCompositeTests TestCheatSheetManagerEvents ‑ testOneHandler
AllTests AllCheatSheetTests AllCompositeTests TestCheatSheetManagerEvents ‑ testTwoHandlers
AllTests AllCheatSheetTests AllCompositeTests TestCompositeParser ‑ testBackwardDependency
AllTests AllCheatSheetTests AllCompositeTests TestCompositeParser ‑ testBadURL
AllTests AllCheatSheetTests AllCompositeTests TestCompositeParser ‑ testChoiceNoChild
AllTests AllCheatSheetTests AllCompositeTests TestCompositeParser ‑ testCircularDependency
AllTests AllCheatSheetTests AllCompositeTests TestCompositeParser ‑ testCompositeNoName
AllTests AllCheatSheetTests AllCompositeTests TestCompositeParser ‑ testDependency
AllTests AllCheatSheetTests AllCompositeTests TestCompositeParser ‑ testDependencyWithInvalidId
…

♻️ 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. :)

[HannesWell]

Let's add a MAX segment in these names to reflect that these are the maximum values:

Suggested change

	private static final int RSA_KEY_SIZE = 15360;
	private static final int DSA_KEY_SIZE = 3072;
	private static final int RSA_MAX_KEY_SIZE = 15360;
	private static final int DSA_MAX_KEY_SIZE = 3072;

[HannesWell]

These constants are not needed.

Suggested change

	private static final int MAX_KEY_SIZE = RSA_KEY_SIZE;
	private static final int MAX_KEY_SIZE_DIGIT_COUNT = 0;

[HannesWell]

This can be structured a bit more to prevent an over-long line and two constants:

Suggested change

	keySizeValue.setValues(INITIAL_KEY_SIZE, MIN_KEY_SIZE, MAX_KEY_SIZE, MAX_KEY_SIZE_DIGIT_COUNT,
	KEY_SIZE_INCREMENT, KEY_SIZE_INCREMENT);
	int maxKeySize = Math.max(DSA_MAX_KEY_SIZE, RSA_MAX_KEY_SIZE);
	keySizeValue.setValues(INITIAL_KEY_SIZE, MIN_KEY_SIZE, maxKeySize, 0, KEY_SIZE_INCREMENT, KEY_SIZE_INCREMENT);

[HannesWell]

Adapt to new constant names

Suggested change

	if (keySizeValue.getSelection() > DSA_KEY_SIZE) {
	keySizeValue.setSelection(DSA_KEY_SIZE);
	if (keySizeValue.getSelection() > DSA_MAX_KEY_SIZE) {
	keySizeValue.setSelection(DSA_MAX_KEY_SIZE);

[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.