Use hardware-accelerated AES CryptoServiceProvider

[zybexXL]

This feature reduces CPU usage dramatically, allowing higher SFTP performance on slower machines. It does so by using the AesCryptoServiceProvider for AES CBC/CTR/ECB encryption/decryption, which taps into AES-NI accelerated OS functions.

STFP download performance testcases:

Test case A: 4 year-old i5-7300U 2-core/4-threads laptop, 250Mbps internet connection:

• Before: 13.15MB/sec, one CPU thread fully saturated
• After: 24.50 MB/sec (+86%), limited by internet connection, main thread at around 20-30% (5-10% in Task Manager)

Test case B: 4 year old I7-7700 4-core/8-threads, 500Mbps internet connection:

• Before: 40.85 MB/sec, one CPU-thread fully saturated
• After: 66.70 MB/sec (+63%), limited by internet connection, main thread at around 30-40% (5-10% in Task Manager)

Note: all values above were taken with PR #866 also merged in. Tested with sftpClient.DownloadFile()

SSH.NET vs AES-NI benchmarks

SSH.NET implements AES as pure managed code. CPUs nowadays have hardware acceleration for AES via the AES-NI instruction set, and .NET provides APIs to the OS functions that make use of it. There are 3 .NET providers for AES:

AesManaged : older managed-only implementation, not accelerated. Still faster than the current SSH.Net
AesCryptoServiceProvider: call into the OS and makes use of AES-NI if available
AesCNG (CryptoNewGen): newer Crypto API, available since 2018 in Win10. Also makes use of AES-NI and has less overhead

Here are some benchmarks (executed on the dual-core laptop...):

Provider Mode Iterations Average
---------- ---- --------------------------------------- ------------
SSH.NET CTR 29.44 29.75 29.41 29.81 28.69 => 29.42 MB/s
SSH.NET CBC 24.72 28.47 28.34 28.59 28.81 => 27.79 MB/s
SSH.NET ECB 33.75 33.50 25.34 27.56 23.53 => 28.74 MB/s
SSH.NET CFB 27.81 26.41 27.41 27.69 27.56 => 27.38 MB/s
SSH.NET OFB 27.97 28.06 27.75 27.69 27.75 => 27.84 MB/s
AesManaged CBC 41.19 41.50 41.72 41.78 25.66 => 38.37 MB/s
AesCSP CBC 717.06 777.25 828.03 815.72 812.75 => 790.16 MB/s (AES-NI)
AesCNG CBC 830.16 847.25 852.72 853.06 832.78 => 843.19 MB/s (AES-NI)

As you can see, the accelerated APIs are about 25x faster than the current managed code!

Since AesCNG is too new I chose to use AesCryptoServiceProvider. This supports CBC and ECB natively, but not CFB or OFB (which are not listed in the SSH.Net protocol list anyway). For CTR (used by AWS SFTP Transfer Family), my code uses ECB followed by XOR. This would be extremely fast on C/C++ (or using unsafe tag in C# to allow memory pointers), but on pure C# I had to do a few memory Blockcopy to convert between byte[] and uint[], so the result is not ideal - however, it's still about 10x faster than the previous code.

Here's the new AES benchmarks with this PR:

Provider Mode Iterations Average
---------- ---- --------------------------------------- ------------
SSH.NET+ CTR 316.53 317.69 315.72 305.00 308.53 => 312.69 MB/s (1063%)
SSH.NET+ CBC 768.03 744.16 772.19 781.16 761.41 => 765.39 MB/s (2754%)
SSH.NET+ ECB 2368.78 2370.50 2393.44 2368.03 2344.53 => 2369.06 MB/s (8243%)
SSH.NET+ CFB 27.31 27.78 26.91 27.81 26.66 => 27.29 MB/s (100%)
SSH.NET+ OFB 28.41 27.91 28.25 28.38 27.97 => 28.18 MB/s (101%)

These CTR and CBC values are now the new maximum theoretical SFTP performance of SSH.NET 😎

[jjxtra]

Well that's pretty good!

[IgorMilavec]

CTRArrayXOR can be optimized on supported platforms with the use of Vector<T>. It's faster and allocation free:

Method	Size	Mean	Error	StdDev	Gen 0	Allocated
Original	128	123.07 ns	2.455 ns	3.823 ns	0.0968	304 B
Vector	128	21.87 ns	0.101 ns	0.090 ns	-	-
Original	256	184.98 ns	1.866 ns	1.745 ns	0.1783	560 B
Vector	256	38.55 ns	0.096 ns	0.085 ns	-	-
Original	512	349.29 ns	10.298 ns	30.363 ns	0.3414	1,072 B
Vector	512	81.09 ns	0.251 ns	0.235 ns	-	-

Here is the code I used:

byte[]CTRArrayXOR(byte[]counter,byte[]data,intoffset,intlength){for(intloopOffset=0;length>0;length-=Vector<byte>.Count){varv=newVector<byte>(counter,loopOffset)^newVector<byte>(data,offset+loopOffset);if(length>=Vector<byte>.Count){v.CopyTo(counter,loopOffset);loopOffset+=Vector<byte>.Count;}else{for(inti=0;i<length;i++){counter[loopOffset++]=v[i];}}}returncounter;}

[zybexXL]

I've tested your snippet by replacing the XOR on my AES-CTR benchmark, which processes chunks of 32KB of random data (similar to what happens when downloading a file)
My current code: ~300MB/sec
Your code: ~150MB/sec

Note that my code copies the byte[] to uint[] so that the XOR is not done byte by byte. Does your benchmark take that into account? Is the "original" my PR code (accelerated), or the existing SSH-NET code?

You mention that vector<T> doesn't need to allocate memory... I think that's not exactly true. That FOR loop instantiates 2 Vector<byte> objects, each holding 4 bytes. Due to the limited scope the objects are immediately discarded after each loop. So it's still allocating 16384 objects in the stack in that FOR loop to XOR the two 32KB arrays. Instantiating objects is not free.

I see that vector<T> is likely optimized by the compiler to use CPU registers. Even so, it seems slower than my current code.

[zybexXL]

I recompiled the benchmark for NetCore 5.0 and added 3 versions of CTR:

• BlockCopy (current code in this PR, copying byte[] to uint[] before XOR)
• Vector<T> (IgorMilavec's suggestion)
• Span<T> (allowing cast from byte[] to uint[] without memcopy)

Running it as Release instead of Debug also kicked performance by a lot, and changes the ranking. So here are the results:

Benchmark	Average
SSH.NET CTR 2020.0.1	49.06 MB/s
SSH.NET CTR BlockCopy	586.66 MB/s
SSH.NET CTR Span<T>	671.85 MB/s
SSH.NET CTR Vector<T>	731.97 MB/s
AesCSP CBC	785.79 MB/s

So Vector is indeed the fastest, but available only since NetStandard 2.1 (like Span). Blockcopy is not that bad considering it's available for all platforms, and it's still 13x faster than base. We can add a separate PR with Vector/Span later on if needed.

Here's the snippet for SpanXOR - it assumes the arrays are 4-byte aligned for simplification:

privatebyte[]SpanXOR(byte[]data,intoffset,byte[]output){intuOffset=offset/4;Span<uint>uData=MemoryMarshal.Cast<byte,uint>(data);Span<uint>uOut=MemoryMarshal.Cast<byte,uint>(output);for(inti=0;i<uOut.Length;i++)uOut[i]=uOut[i]^uData[i+uOffset];returnoutput;}

[IgorMilavec]

@drieseng This looks fine. I've been using it in production for a couple of months without any side effects. With 10x performance improvement, I propose to merge this before the next release.

[A9G-Data-Droid]

I have tested this and it works!

[zybexXL]

I've rebased this PR, please review and consider merging.
I have been using this code since 2021 and I still see the huge performance gains this provides, together with #866

[Rob-Hague]

I'm very much in favour of this change, but I think the design needs some work. In fact, I think it can be much simpler as a starting point: I think we can just replace the implementation of AesCipher with an ICryptoTransform in ECB mode and no padding.

That way, we still use the given CipherMode object (rather than subverting it) which is more predictable, testable and yet we should still get the majority of the performance gains. The CipherModes can easily be optimized as a next step, and then further down the line (if we are still not satisfied) we can think about increasing the complexity in order to delegate to the BCL for the cipher modes too.

If you have any thoughts on this approach, or would like to work on it, let me know. Otherwise, I will play with it.

[zybexXL]

All AES tests pass (including the new ones from #1232). The failed test is unrelated, seems spurious:

Failed CanWriteShouldReturnFalse [9 ms]
Error Message:
Initialization method Renci.SshNet.Tests.Classes.Sftp.SftpFileStreamTest_CanWrite_Closed_FileAccessReadWrite.SetUp threw exception. System.ArgumentOutOfRangeException: Cannot be less than or equal to zero. (Parameter 'bufferSize').

Is there a way to force re-run of the test suite without doing a dummy commit?

[WojciechNagorski]

I've merged #1232 can you update this PR and check if all tests passed?

[zybexXL]

DST messed up the order of comments, my comment above was actually made after Wojciech's.
AES tests passed.

[zybexXL]

I'm very much in favour of this change, but I think the design needs some work. In fact, I think it can be much simpler as a starting point: I think we can just replace the implementation of AesCipher with an ICryptoTransform in ECB mode and no padding.

That way, we still use the given CipherMode object (rather than subverting it) which is more predictable, testable and yet we should still get the majority of the performance gains. The CipherModes can easily be optimized as a next step, and then further down the line (if we are still not satisfied) we can think about increasing the complexity in order to delegate to the BCL for the cipher modes too.

If you have any thoughts on this approach, or would like to work on it, let me know. Otherwise, I will play with it.

@Rob-Hague
ECB by itself is not enough. My main goal with this code was to improve performance with AWS SFTP, which uses CTR.
When I added this PR 3 years ago, SSH.Net still included many legacy frameworks which did not support the accelerated AESCryptoProvider API, so I left the legacy/slow ECB code in place and surrounded the new code with the FEATURE_AES_CSP conditional.

With the removal of the legacy frameworks perhaps we can get rid of the legacy code and just use this new one. However, I think we should first merge this in, and then rework and remove the legacy code in a separate PR.

[Rob-Hague]

With the removal of the legacy frameworks perhaps we can get rid of the legacy code and just use this new one. However, I think we should first merge this in, and then rework and remove the legacy code in a separate PR.

Let's get it right in this PR.

My biggest concern is the subversion of logic. When passing a CipherMode object, my expectation is that this object is going to be used in the cipher process (as it always has done). But with this change, the object is only used as a type check and the implementation is not touched. This is unexpected.

I have run some experiments with the following changes to the benchmarks:

Details

diff --git a/test/Renci.SshNet.Benchmarks/Security/Cryptography/Ciphers/AesCipherBenchmarks.cs b/test/Renci.SshNet.Benchmarks/Security/Cryptography/Ciphers/AesCipherBenchmarks.cs
index ff414cc4..b91e3b8a 100644
--- a/test/Renci.SshNet.Benchmarks/Security/Cryptography/Ciphers/AesCipherBenchmarks.cs+++ b/test/Renci.SshNet.Benchmarks/Security/Cryptography/Ciphers/AesCipherBenchmarks.cs@@ -15,7 +15,7 @@ namespace Renci.SshNet.Benchmarks.Security.Cryptography.Ciphers
{
_key = new byte[32];
_iv = new byte[16];
- _data = new byte[256];+ _data = new byte[32 * 1024];
Random random = new(Seed: 12345);
random.NextBytes(_key);
@@ -34,5 +34,29 @@ namespace Renci.SshNet.Benchmarks.Security.Cryptography.Ciphers
{
return new AesCipher(_key, new CbcCipherMode(_iv), null).Decrypt(_data);
}
++ [Benchmark]+ public byte[] Encrypt_CFB()+ {+ return new AesCipher(_key, new CfbCipherMode(_iv), null).Encrypt(_data);+ }++ [Benchmark]+ public byte[] Decrypt_CFB()+ {+ return new AesCipher(_key, new CfbCipherMode(_iv), null).Decrypt(_data);+ }++ [Benchmark]+ public byte[] Encrypt_CTR()+ {+ return new AesCipher(_key, new CtrCipherMode(_iv), null).Encrypt(_data);+ }++ [Benchmark]+ public byte[] Decrypt_CTR()+ {+ return new AesCipher(_key, new CtrCipherMode(_iv), null).Decrypt(_data);+ }
}
}

Results on develop branch 826222f:

Method	Mean	Error	StdDev	Gen0	Allocated
Encrypt_CBC	320.4 μs	0.47 μs	0.36 μs	15.6250	32.41 KB
Decrypt_CBC	352.3 μs	2.37 μs	1.85 μs	15.6250	32.41 KB
Encrypt_CFB	335.6 μs	0.43 μs	0.34 μs	15.6250	32.45 KB
Decrypt_CFB	367.9 μs	4.23 μs	3.95 μs	15.6250	32.45 KB
Encrypt_CTR	310.4 μs	0.38 μs	0.31 μs	15.6250	32.45 KB
Decrypt_CTR	315.3 μs	3.96 μs	3.70 μs	15.6250	32.45 KB

Results on my suggestion to replace the AesCipher implementation with the BCL Rob-Hague@8619062

Method	Mean	Error	StdDev	Gen0	Allocated
Encrypt_CBC	221.2 μs	2.01 μs	1.88 μs	15.8691	32.7 KB
Decrypt_CBC	220.0 μs	2.73 μs	2.56 μs	15.8691	32.71 KB
Encrypt_CFB	251.3 μs	0.33 μs	0.27 μs	15.6250	32.75 KB
Decrypt_CFB	255.3 μs	0.67 μs	0.60 μs	15.6250	32.75 KB
Encrypt_CTR	201.3 μs	0.41 μs	0.38 μs	15.8691	32.75 KB
Decrypt_CTR	209.3 μs	0.22 μs	0.19 μs	15.8691	32.75 KB

Results on your branch zybexXL@a9f68fb

Method	Mean	Error	StdDev	Gen0	Allocated
Encrypt_CBC	29.637 μs	0.1278 μs	0.1067 μs	16.1133	33.14 KB
Decrypt_CBC	6.579 μs	0.0160 μs	0.0142 μs	16.1285	33.14 KB
Encrypt_CFB	333.761 μs	0.1710 μs	0.1335 μs	15.6250	32.52 KB
Decrypt_CFB	333.899 μs	0.2090 μs	0.1955 μs	15.6250	32.52 KB
Encrypt_CTR	24.630 μs	0.0327 μs	0.0273 μs	78.1250	161.2 KB
Decrypt_CTR	24.544 μs	0.0817 μs	0.0683 μs	78.1250	161.2 KB

So my suggestion gets moderate gains but clearly we can do a lot better with an approach to delegate the entire encryption to the BCL (rather than block-by-block).

So here is what I propose:

We keep the behaviour of the existing constructor on AesCipher as is. That is, if you pass a CipherMode and/or CipherPadding object then they will be used as expected, with encryption happening block-by-block using the BCL as in my branch.

We add a new constructor which will allow delegating to the BCL for the entire encryption process. This will achieve the much better performance and separation from the existing behaviour.

publicAesCipher(System.Security.Cryptography.CipherMode cipherMode,System.Security.Cryptography.PaddingMode paddingMode,bool ctrMode = false){}

Since S.S.C.CipherMode does not have a CTR value, there is a ctrMode parameter. The constructor would throw if ctrMode is true and cipherMode != ECB. A bit awkward, but it should work fine. Other ideas would be to define our own CipherMode enum which does contain a CTR value, or to allow passing e.g. (S.S.C.CipherMode)-1 which we interpret as CTR.

In terms of the design, we define nested classes in AesCipher which represent the different implementations. Essentially, AesCipher becomes:

publicsealedclassAesCipher:BlockCipher{privatereadonlyBlockCipher_impl;publicAesCipher(byte[]key,CipherModemode,CipherPaddingpadding):base(key,16,mode,padding){_impl=newSshNetCipherModeImpl(key,mode,padding);}publicAesCipher(byte[]key,byte[]iv,System.Security.Cryptography.CipherModecipherMode,System.Security.Cryptography.PaddingModepaddingMode,boolctrMode=false){_impl=newBclImpl(/* ... */);}// AesCipher just forwards all implementation to _implpublicoverrideintEncryptBlock(byte[]inputBuffer,intinputOffset,intinputCount,byte[]outputBuffer,intoutputOffset){return_impl.EncryptBlock(inputBuffer,inputOffset,inputCount,outputBuffer,outputOffset);}publicoverrideintDecryptBlock(byte[]inputBuffer,intinputOffset,intinputCount,byte[]outputBuffer,intoutputOffset){return_impl.DecryptBlock(inputBuffer,inputOffset,inputCount,outputBuffer,outputOffset);}publicoverridebyte[]Encrypt(byte[]input,intoffset,intlength){return_impl.Encrypt(input,offset,length);}publicoverridebyte[]Decrypt(byte[]input){return_impl.Decrypt(input);}publicoverridebyte[]Decrypt(byte[]input,intoffset,intlength){return_impl.Decrypt(input,offset,length);}// Implementations// The block-by-block implementation using instantiated SshNet.CipherMode, SshNet.CipherPadding objectsprivatesealedclassSshNetCipherModeImpl:BlockCipher{privatereadonlyAes_aes;privateICryptoTransform_encryptor;privateICryptoTransform_decryptor;publicSshNetCipherModeImpl(byte[]key,CipherModemode,CipherPaddingpadding):base(key,16,mode,padding){// Initialise _aes in ECB mode}publicoverrideintEncryptBlock(byte[]inputBuffer,intinputOffset,intinputCount,byte[]outputBuffer,intoutputOffset){_encryptor??=_aes.CreateEncryptor();return_encryptor.TransformBlock(inputBuffer,inputOffset,inputCount,outputBuffer,outputOffset);}publicoverrideintDecryptBlock(byte[]inputBuffer,intinputOffset,intinputCount,byte[]outputBuffer,intoutputOffset){_decryptor??=_aes.CreateDecryptor();return_decryptor.TransformBlock(inputBuffer,inputOffset,inputCount,outputBuffer,outputOffset);}}privatesealedclassBclImpl:BlockCipher{// This overrides Encrypt/Decrypt for full BCL perf.publicoverridebyte[]Decrypt(byte[]input){thrownewNotImplementedException();}publicoverridebyte[]Decrypt(byte[]input,intoffset,intlength){thrownewNotImplementedException();}publicoverrideintDecryptBlock(byte[]inputBuffer,intinputOffset,intinputCount,byte[]outputBuffer,intoutputOffset){thrownewNotImplementedException();}publicoverridebyte[]Encrypt(byte[]input,intoffset,intlength){thrownewNotImplementedException();}publicoverrideintEncryptBlock(byte[]inputBuffer,intinputOffset,intinputCount,byte[]outputBuffer,intoutputOffset){thrownewNotImplementedException();}}}

Comments appreciated. Most important to me is that we do not subvert provided SshNet.CipherMode instances.

[Rob-Hague]

Most important to me is that we do not subvert provided SshNet.CipherMode instances.

One other thought: because the proposed new constructor is a bit awkward for CTR mode, I am in principle OK with subverting our own SshNet.CipherMode instances with an exact type check e.g. mode.GetType() == typeof(CtrCipherMode) instead of an is check (which would pass also for derived types which we definitely should not subvert). Then we can stick with one constructor which decides on the implementation, and the awkward logic is not exposed publicly.