Expose native "utilities" like CRC32 calculation, SHA-1, SHA-256

[nfbot]

Create a new C# class library that "taps" into the existing native methods and makes them available to managed apps.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[networkfusion]

Not stale!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[networkfusion]

Still Valid

[SandorDobos]

I found SUPPORT_ComputeCRC and lots of crypto in mbedtls.
Those are the existing native methods?
Do you mean to wire them out to lib-CoreLibrary level, right?
Any suggestions of c# level namespaces, class names?
System.Security.Cryptography and related classes below?

[networkfusion]

They are (I think) existing methods in the native RTOS for most (if not all) boards, so they need exposing to the managed layer. I guess the question is, whether that is in corlib, or another "helper" lib... In all cases, it needs exposed in the managed layer to be truly useful...

BTW, this could be extended (and utility libs exist on the managed layer for things like generating them for connection to Azure when using AMQP).

[networkfusion]

I guess this is an example... https://github.com/networkfusion/NetMfMqttClient/blob/master/src/Gadgeteermqtt/SHA.cs
so would be a new lib called System.Security.Cryptography

[josesimoes]

As the description above tried to explain: the goal is to expose the various utilities that are already available in the native part of the code to C#, thus saving the trouble to added them in their C# form. Not to mention the incurred penalty duplicating code that's already there and with an implementation with less performance.

Worth noting that this is NOT an excuse to add new stuff on the native code, rather expose what's already there. The most basic crypto functions, along with CRC32 are available has hardware implementations in most of mid-high level MCUs, so this becomes available with a minimum cost in code size.

Suggest that we continue this conversation in Discord, class-libraries-general channel, perhaps...

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[josesimoes]

still active

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[josesimoes]

Was looking at this and on a quick search on .NET docs, found System.Runtime.Intrinsics

It has CRC32, SHA1, SHA256, etc pretty much what we're looking into exposing with this.
To me it feels like it better captures our intention and not so much providing hardcore cryptography stuff which we're unlikely to offer and (possibly) doesn't even make sense on embedded systems context.

[Ellerbach]

I'm all in favor of moving some elements to native. We also have to check that those are present in all the native platforms. Otherwise for libs like Azure or AWS which are using those won't be able to work properly. And there is bunch of IoT devices using CRC16, CRC32, etc.

[josesimoes]

Those are available yes. Actually, that's what prompted all this in the 1st place.
It's always there. All the rest are provided by Mbed Tls, which is available in all builds that have network.

[josesimoes]

I'm taking back what I've wrote above... 😊 It seems that most of what we need to have exposed (despite several are in the Intrinsics namespace) is better fitted in Cryptography namespace. The "alien" class there will be CRC32 which doesn't exist on the full framework. But we've done it in the past with other APIs and we'll do it again: extend it with what we have. 😉

[josesimoes]

Turns out that there is a .NET API for CRC32! System.IO.Hashing.
I'm thinking that we're better releasing two NuGets: one for this and another for the Cryptography namespace.

[Ellerbach]

Turns out that there is a .NET API for CRC32! System.IO.Hashing.

That's a discovery for me! And a great news. It means we definitely can do all this then. Quite some work ahead but it will bring robustness in all this.