search

nanoframework / Home

:house: The landing page for .NET nanoFramework repositories.
https://www.nanoframework.net
MIT License
856 stars 78 forks source link

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

Open nfbot opened 3 years ago

nfbot commented 3 years ago

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

stale[bot] commented 3 years ago

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 commented 3 years ago

Not stale!

stale[bot] commented 3 years ago

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 commented 3 years ago

Still Valid

SandorDobos commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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[bot] commented 3 years ago

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 commented 3 years ago

still active

stale[bot] commented 3 years ago

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[bot] commented 2 years ago

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[bot] commented 2 years ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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.