JSCH 0.2.0 not working with bcfips

[ihudedi]

Hi, I tried to use ssh-ed25519 as my server_host_key but it's failing due to the fact that jcsh use hard codes files from bouncy castle and some packages are different from bouncy castle and bouncy castle fips For example when using this file SignatureEdDSA he use org.bouncycastle.crypto.Signer and this class doesn't exists in the bcfips jar. Therefore all classes that use bouncy castle may fail when we use bouncy castle fips jars. Is there an option to use those classes according to the provider loaded. Thanks, Itay

[norrisjeremy]

Hi @ihudedi,

It appears the Bouncy Castle FIPS releases are not freely available, so it is unlikely we would be able to correct this issue. You are welcome to submit a PR for us to review to add support since you have access to them however.

Thanks, Jeremy

[ihudedi]

Hi @norrisjeremy BC FIPS is released since 2 years ago. Thanks, Itay

[avnerw74]

Hi @norrisjeremy , why isn't it freely available? It is published in maven repository: https://mvnrepository.com/artifact/org.bouncycastle/bc-fips/1.0.2.3 Thanks, Avner

[norrisjeremy]

Yes, apologies, my searches in Maven Central failed yesterday because I thought it would be named bcfips not bc-fips, and their website does a poor job of documenting the fact that it is actually freely available.

That said, I'm not immediately motivated to support this. However, you are welcome to submit a PR implementing support for it (I'd suggest creating a com.jcraft.jsch.bcfips package to drop implementations into).

[Alex-Vol-Amz]

I spent some time working on this and came to the following conclusions.

• The bc-fips library requires a different module name than the bcprov library, as such it is not possible to make a simple swap of one for the other, it would break the module requirement and would not load in a module enabled environment.
• The changes to make bc-fips function are more than simple remapping of classes. Aside from some disallowed algorithms when operating in FIPS approved mode the majority of implementation classes are no longer constructor enabled in FIPS library. Instead a number of factory patterns are invoked to provide access to interface only classes matching some of the previously directly allowed class implementations.

Given the above restrictions I propose that the BouncyCastle support is refactored to have an optional module interface, that module would not expose any of the BC classes in the interface and encapsulate the implementations under a common facade. With that in place and assuming we can provide a class compatible interface for all the current bcprov implementations under com.jcraft.jsch.bc we can have an initial release that supports the current BC module as an optional loaded module from the classpath. i.e. one would have to explicitly provide the new jsch-bc module/jar together with the required bcprov non-FIPS JAR file to enable standard BouncyCastle functionality. Then a separate module providing the same external module signature but using BCFIPS would be created and again loaded by having the necessary pair of JAR files in the classpath.

Using this approach the BC or BCFIPS modules would have an explicit requires module declaration matching the chosen BC or BCFIPS module identifier. At the same time the JSCH module would declare the shared module identifier on our adapter module and the solution becomes evident.

I started working on this in my spare time and quickly found that we need to agree on the approach outlined above before I spend too much time as it is quite consuming changing the current implementation to fit the factory based model imposed by the BCFIPS library. And working with Cryptographic modules is hard enough on its own without the additional headaches of the Java Module System.

Thoughts? I would appreciate any feedback you have.

[norrisjeremy]

To be honest, I'm not terribly keen on attempting to support the bc-fips releases: I only added the regular Bouncy Castle support to provide an easy way to support newer (stronger) crypto algorithms on older Java releases.

Is there some reason that bc-fips can't simply be configured as your JCE provider in your JVM, which should then allow you to use the regular com.jcraft.jsch.jce implementations?

[Alex-Vol-Amz]

That is a very excellent point. bc-fips does provide a proper JCE provider that can be made available as a configured option in the JVM. Then there are no changes needed and the JCE equvalent implementations work.