#111 java.security.SignatureException: Invalid encoding for signature

[Mark]

I get the following exception (I know it is not much to go by) and I would guess it may have to do with how JSch uses BASE64 encoding/decoding. Can someone confirm that the following openjdk behaviour does not affect this library?

From https://bugs.openjdk.java.net/browse/JDK-8174719
( Java8u121: signature.verify throws exception Invalid encoding for signature )

valeriep Valerie Peng added a comment - 2017-02-27 18:05 - edited
Thanks for the clarification.
Based on the provided info, I think the trailing 0s are introduced during the BASE64 encoding process.
The BASE64 decoding process didn't correctly strip off these trailing 0s.
You should use the "=" pad char or keep track of how long the original byte[] is when doing your BASE64 encoding/decoding.
The byte[] passed into Signature.verify(byte[]) call needs to be exactly the bytes returned by Signature.sign(). It cannot contain any extra bytes. There is no problem with the current implementation. The earlier implementation in JDK 8u112 is incorrect and although we try our best to maintain backward compatibility, we have to fix this to ensure that signature verification is done properly.

This will be closed as "Not an Issue" or "Will Not Fix".

Exception stacktrace -

Caused by: com.jcraft.jsch.JSchException: Session.connect: java.security.SignatureException: Invalid encoding for signature
        at com.jcraft.jsch.Session.connect(Session.java:565)
        at com.jcraft.jsch.Session.connect(Session.java:183)

Java environment details -

$ java -version
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

JSch version details

<dependency>
    <groupId>com.jcraft</groupId>
    <artifactId>jsch</artifactId>
    <version>0.1.54</version>
</dependency>

See also -
* This issue looks very similar to https://sourceforge.net/p/jsch/bugs/96/

[Pablo Musumeci]

I'm running into the same problem here. Is there any update about this particular issue? Is there going to be a fix soon?

[Mark]

In my environment, I discovered that this issue is intermittent, so I built a retry mechanism when it fails. Thus far I haven't been in a situation where it has failed more than 5 times in a row.

[Rob Brueckmann]

We are having the EXACT same issue as Mark above - it's completely and totally intermittent. Has there been any progress in getting a build that fixes this issue introduced by Oracle releasing u121 that supposedly fixes soemthing broken in u112 that apparently JSch 0.1.54 was depending on that now introduces a completely random and intermittent failure now?

I REALLY do not have the bandwidth to swap out for a new SSH Java lib, so if there is a build coming, could someone please let us know?

Thanks so much!

[William Laird]

We're also impacted by this. Does anyone have a good reproducer? Is it specific to certain environements, like windows server?

[Fabian Gonzalez]

Any updates concerning this bug?

[Jurrie Overgoor]

Hello everyone,

I've traced this to be a bug in the conversion of mpint (which SSH uses) to ASN.1 (which JCA expects). It's in SignatureDSA.java. I've fixed this and notified the JSCH team, but as I need the fix myself (and right now) I've published a Maven artifact that you can use to fix this bug. It contains an alternative implementation of SignatureDSA.java.

Please see https://github.com/Jurrie/jsch-111-bugfix for more information.

By the way: during testing I also hit another bug. When the first integer in the hash is very small (starts with 0x00, 0x00, 0x00), JSCH incorrectly assumes it to be the SSH identification string exchange message, and hash verification fails. This bug wouldn't surface that often, but still I managed to hit it. My alternative implementation now checks the first 8 bytes instead of the first 3. This doesn't prevent the bug, but reduces the chance of it surfacing drastically.

With kind regards,

Jurrie

[Fabian Gonzalez]

I've tested your fix and it works (at least for the cases where I got an Invalid encoding exception with a SFTP server using DSA as algorithm).

Thank you very much!

I hope this will be included in the following jsch release.

[Charles Gould]

Nice find. Re: the identification string exchange, it might be helpful to explain in the code that "0:0:0:7:73:73:68:2d" maps to "SSH-" (well, technically "<NUL><NUL><NUL><BEL>SSH-") which according to RFC 4253 must be the start of all SSH identification strings.

Also, do you mind if I port your code changes and unit tests to sshj?
https://github.com/hierynomus/sshj/issues/354

[Jurrie Overgoor]

Thanks!

I would see it as a compliment if you ported the code changes and/or unit test to sshj. If you could mention me somewhere, that would be great. (Not required of course.)

I agree on your suggestion to explain that "0:0:0:7:73:73:68:2d" maps to "SSH-". However, I don't consider that change a valid fix. It's just to reduce the risk of hitting such a hash; it doesn't stop it from happening. I think the authors of JSch should fix it in another way.

Do note though that the "0:0:0:7:73:73:68:2d" change has nothing to do with the "java.security.SignatureException: Invalid encoding for signature" error (JSch bug #111). They are two different fixes. That was probably clear to you already, but I thought it couldn't hurt to point it out anyway :)

Jurrie

[Ankit]

Hi Jurrie,

I am not able to open github. can you please share your fix using any other medium. Thanks

[Jurrie Overgoor]

Hello Ankit,

Are you able to download from Maven Central?
jsch-111-bugfix-1.0.0.jar
jsch-111-bugfix-1.0.0-sources.jar

With kind regards,

Jurrie

[Fabian Gonzalez]

Hello,

Any news from jsch if this is being considered for the next release?

Thanks

[Guenther Demetz]

We're also affected by this bug. It does happen accidentally once a while.
As it's not critical for us, we wait the next release, hoping JSCH team will release it soon.

[Paul Nyheim]

We're also affected by this one. And as stated above, it only happens sporadically.

It would be nice to get some "official" response from the team/developer behind jsch on this issue.

Regards,
Paul

[Erwin Vervaet]

We were also hit by this problem in our test suite where we're testing against an SshServer configured with a SimpleGeneratorHostKeyProvider using the default DSA algorithm.
As a work-around, we've now just switched to the RSA algorithm:

SshServer sshd = ...;
sshd.setKeyPairProvider(new SimpleGeneratorHostKeyProvider("target/hostkey.ser", "RSA));
...
sshd.start();

[Geoffrey Wiseman]

I'm seeing this on one of my servers -- the fact that it has been reported and a fix available for six months and no comment from JSch is not reassuring. :/

[Guenther Demetz]

The release notes of jsch-0.1.55 which was released 3 days ago among other says:

-bugfix: fixed 'Invalid encoding for signature' errors in ssh-dss.

I 'm wondering if this fixes also this issue....

[Jurrie Overgoor]

It's been a while since I wrote my fix, so the details are a bit vague. But I wrote a unit test that fails on 0.1.54 with the error in question, and succeeds on 0.1.55. So I think the 0.1.55 release does actually fix this issue.
I'm a little bit disappointed that the JSch team did not contact me, or mention me. Oh well, that's life I suppose :)

[Rahul Makwana]

Good Job Jurrie.Don't get disappointed with JSch team.Keep up the Good work. You have helped many individual Groups in resolving this way before JSch team came up with solution.:)