Performance optimizations

[tomaswolf]

A series of performance optimizations:

• Manual optimizations in the ChaCha20-Poly1305 cipher implementation (loop unrolling, use int instead of long where possible, avoid unnecessary method calls).
• Optimize writing ints/longs into buffers.
• Avoid copying buffers if possible. If we prepare an SSH packet buffer, we should avoid copying it later on if possible.
• Streamline SFTP OutputStreams. Give them a transferFrom operation to be able to read directly into an internal buffer, and internally read-ahead into a second buffer while the first one is being sent.
• Add a convenience operation SftpClient.put() for uploading.
• Avoid using the AES implementation from Bouncy Castle (typically a Java implementation). Prefer the one from SunJCE, which uses native code.

[gnodet]

In chacha20-poly1305, would it make sense to use a different mechanism for unpackIntLE and packIntLE, such as using Unsafe or VarHandle ?

I've also seen that there is a multithreaded implementation of chacha20-poly1305 which seems to be much faster, not sure if there's anything that could be useful.

[gnodet]

In chacha20-poly1305, would it make sense to use a different mechanism for unpackIntLE and packIntLE, such as using Unsafe or VarHandle ?

I've also seen that there is a multithreaded implementation of chacha20-poly1305, not sure if there's anything that could be useful.

Also chacha20-poly1305 is supported since JDK 11. How do both performs ?

[tomaswolf]

Haven't looked at further optimizations. Most of the time is spent in Poly1305.processBlock() anyway. We could continue looking at trying to make this cipher and mac faster, but for now I think a 40% improvement and being nearly as fast as native AES (in my benchmarks) is good enough.

I don't think the Java built-in ChaCha20-Poly1305 can be used for SSH. SSH uses a 64bit nonce and 64bit counter, while the JDK uses a 96bit nonce and 32bit counter.

[tomaswolf]

In chacha20-poly1305, would it make sense to use a different mechanism for unpackIntLE and packIntLE, such as using Unsafe or VarHandle ?

VarHandle doesn't exist in Java 8. But ByteBuffer.wrap(someByteArray).order(ByteOrder.LITTLE_ENDIAN).asIntBuffer() does.

However, using IntBuffer.put() instead of packIntLE(), and processing ints via IntBuffers, makes matters
worse on Java 8 (a slow-down of 20-30% compared to the version in this PR at commit e152cc3). Benchmarked
with an older JDK 8 (1.8.0_201) and with a brand-new 1.8.0_422.

On Java 11, benchmarking shows a speed improvement of 5%, on Java 17 of 9%. (Again, with commit e152cc3 as baseline.)

The problem is that on Java 8 the ByteBufferAsIntBufferL implementation ends up doing exactly the same as
our packLE/unpackLE routines. So trying to process ints for whole blocks is going to do lots of conversions
to assemble bytes into ints, or split an int into its four bytes. So it's definitely not worth it on Java 8.

On Java 11 or newer, ByteBufferAsIntBufferL is much more efficient and can write or read whole ints.
Only then does such a change make sense.

But we could make the choice at run-time, based on the Java version we're running on, using IntBuffers only
for Java >= 11. Or we could try a multi-release JAR for sshd-common (and sshd-osgi).

Either way, I'd prefer not to attempt that in this PR. If we do something like this, let's do it in some
later commit.

...multithreaded implementation of chacha20-poly1305...

The idea is that one can pre-compute the ChaCha20 key stream asynchronously. This may indeed give some
improvements for file transfers. An implementation might be not quite trivial, though, and it may mean
that we'd need at least one extra thread for every connection that uses ChaCha20-Poly1305. Which might
be a problem for a server, or also for a client doing many connections in parallel. Maybe it would need
another fixed-size thread pool, and fall back to compute the key stream synchronously if not precomputed
yet when it's needed. In any case, not trivial to get right. The Poly1305 mac computation cannot be offloaded
in that way.

[tomaswolf]

I don't think the Java built-in ChaCha20-Poly1305 can be used for SSH.

Indeed it cannot, but mainly because the Poly1305 setup is done differently. The IETF version from RFC 8439 is just not the same as the SSH version of ChaCha20-Poly1305. But on Java 11 or newer, one can use the simple "ChaCha20" cipher from the standard SunJCE provider as a replacement for our ChaChaEngine, and do the special Poly1305 setup as we do now. The 96-32bit vs. 64-64bit difference can be dealt with. Unfortunately SunJCE does not provide a plain Poly1305 mac (see JDK-8253394), so that one would still be hand-written code.

Such a ChaCha20-Poly1305 based on javax.crypto.Cipher.getInstance("ChaCha20", "SunJCE"); and our Poly1305Mac is again faster than any games we can play with IntBuffer, so if one wants to have different implementations per Java version, I'd take this approach.

For Java 8, I have not found anything better than the version from commit e152cc3.

[tomaswolf]

@gnodet: could we do a bug fix release first before merging this? See the mailing list.

[gnodet]

@gnodet: could we do a bug fix release first before merging this? See the mailing list.

Sure, I was assuming you wanted to include that one too.