Runtime: Missing CFB cipher mode

[lextm]

Currently only three modes are supported by .NET Core, (CBC = 1, CTS = 5, ECB = 2). Is there any plan to add CFB support as it has been required by some network protocols (such as SNMP v3)? This mode is available on .NET Framework though.

From where does the limitation of three modes come? The comment in CipherMode does not reveal enough background information.

https://github.com/dotnet/corefx/blob/master/src/System.Security.Cryptography.Primitives/src/System/Security/Cryptography/CipherMode.cs

[CodesInChaos]

Even in the full framework, AesManaged doesn't implement CFB (while RijndaelManaged does).

[CodesInChaos]

If you implement it, please do it properly. There is no reason to restrict the length of the data to a multiple of the block size, when using a stream cipher mode like CFB.

[bartonjs]

The identifiers have been brought back as a part of the netstandard2.0 effort; but at this time there still aren't CFB implementations available in .NET Core (it being pretty scatter-shot in the .NET Framework). I was going to say "because Windows CNG doesn't expose it", but while OFB is not exposed CFB does seem to be; so perhaps this would be feasible.

[karelz]

@lextm do you know how well it is supported in Desktop .NET Framework? If not everything supports it, we wonder if it is really necessary in .NET Core.

[lextm]

As @CodesInChaos indicates the encryption goes through RijndaelManaged class,

https://github.com/lextm/sharpsnmplib/blob/master/SharpSnmpLib/Security/AESPrivacyProvider.cs#L128

It runs fine on full .NET Framework for years, so I was hoping it could be implemented.

Thus, I listed more info below to see if we can now assert whether it should be dropped.

1. SNMP is still a widely used protocol.
2. The certain AES CFB mode was chosen by IETF for SNMP in 2000s, and there is no easy way to change to another mode.
3. AES CFB is supported on Mono across the platforms.
4. It seems to me only a few Windows variants (Windows Phone alike) do not support it.

Then, there can be several options for us,

1. No AES CFB (today it is). Then I think users can inject this mode on certain platforms (like dependency injection).
2. Full AES CFB. Make it work everywhere. This might have an impact on systems where native support is missing.
3. Some AES CFB. Add the support to .NET Core, but throw NotSupportedException when the underlying system does not support it.

I am OK with 1, but prefer 2 or 3 can be achieved.

[mattzink]

We are hitting this exact same issue. SNMP _only_ supports CFB, so there isn't really any other workaround

[NiclasOlofsson]

Lack this to be able to port https://github.com/NiclasOlofsson/MiNET over to .NET core. I'm forced to use BouncyCastle right now, and whatever performance gain I got out of .NET core is eaten up by bad performance on encryption.

[gleocadie]

Coming from dotnet/corefx#32689

Can you clarify what you mean by "(default)" in:

We cipher and decipher data using TripleDES and AES algorithms using the CFB mode (default).

The default mode has always been CBC as far as I am aware. Perhaps you mean a default for something else.

My bad for the unclear definition of default: What I meant was that we use the corresponding Providers (e.g.: AesCryptoServiceProvider) with CFB mode without modifying the FeedbackSize. Which means that for 3DES and CFB, the feedback size is 8 and for AES and CFB the feedback size is 8.

My humble opinion is that the crypto primitive story in .NET Core is somewhat fragmented right now > across platforms. I would not want to continue that trend. We should only do this unless there is a plan to do Windows/CNG and macOS/Security Transforms as well.

I understand and thank you for sharing your vision about it.

What is your priority on adding back the CFB mode? (milestone, timeframe…)

[bartonjs]

What is your priority on adding back the CFB mode? (milestone, timeframe…)

CFB is not currently on anyone's schedule. But given that requests keep trickling in I'll mark it as 3.0. You're welcome to do a PR for it, as long as it adds it to all platforms at the same time (and adds tests) :smile:.

[darrenstarr]

AesImplementation.Unix.cs comments :

// Neither OpenSSL nor Cng Aes support CTS mode.
// Cng Aes doesn't seem to support CFB mode, and that would
// require passing in the feedback size. Since Windows doesn't support it,
// we can skip it here, too.

However CNG Docs clearly state that CFB is in fact supported.

OpenSSL also supports it

Apple Common Crypto supports it through CCCryptorCreateWithMode with kCCModeCFB

The comment about passing feedback is valid, but simply requires passing the property.

As others have mentioned, SNMPv3 privacy only supports CFB. SNMP is one of the most important protocols in computer networking.

I would produce a pull request, but I don't have the means to develop for and test on Mac.

This is a really important feature in the crypto libraries. Please make this a priority. If it's left undone, it means that people will code for SNMP without privacy.

[gleocadie]

In our case, we forked and did the plumbing for OpenSSL :/

[mattzink]

@gleocadie Why not create a pull request with your changes?

[bartonjs]

I have some initial tests and the start of CFB-via-CNG at https://github.com/bartonjs/corefx/commits/cipher_modes

I just don't have time to finish tests with TripleDES, DES, and RC2; then also do macOS CommonCrypto and OpenSSL versions... and then negative tests (exceptions for bad feedback size, etc).

If anyone wants to roll with this, a PR providing netfx compatibility that are ready and signed off by the 17th of May will mean it makes 3.0. If it's not signed off by the 17th of May it starts getting iffy, and (assuming I understand the state of the world correctly) June 1st it becomes "definitely not in 3.0".

I merely don't have the time to personally get it done by that deadline.

[gleocadie]

@gleocadie Why not create a pull request with your changes?

@mattzink I did not create a PR because I did not have time to do the implementation for all platforms + tests (requirement for the PR to be accepted)

[darrenstarr]

I've been looking into SymCrypt and have come to the conclusion that there's no particular reason that CFB must be streamlined in code. In the comments for SymCryptCfbEncrypt(), CFB mode appears to just be chaining the underlying cipher and performing the required XOR. It's extremely inefficient in CNG and OpenSSL seems to be pretty much the same on function SymCryptCfbEncrypt().

While I'd like to have a properly supported .NET implementation of the functions, and it is clear that adding CFB could be easily implemented as platform independent in C#, I think I'll just use straight AES support and make a wrapper function for this. If I get it working, I'll see whether it would be possible to make a pull request integrating the work. As @mattzink has pointed out, time is a precious commodity and since a "proper implementation" wouldn't make a difference performance-wise for CFB, there's no reason just writing an encrypt and decrypt function that calls the already existing AES cipher would be a bad idea.

[AGS-hcole]

Would be really helpful to have CFB mode enabled, up

[mattzink]

Bump

[alexrp]

Just ran into this in a project where I unfortunately don't have the luxury of deciding the cipher mode, so I'll add another request to the pile.

This is blocking porting from .NET Framework to .NET Core.

[lextm]

@alexrp It depends on how you plan to port the code. This issue only tells you that so far the built-in classes cannot handle this cipher mode.

Third party libraries such as BouncyCastle have their own implementations of this cipher mode, so you can build upon them if needed.

[nechvatalp]

I also need this for usage of SNMPv3. Hope it gets done in 5.0.