Closed jborean93 closed 1 month ago
Looks like https://github.com/dotnet/runtime/issues/63174 is a blocker for this unless a 3rd party dependency is taken up. Also mentioned by yourself in https://github.com/dotnet/runtime/issues/69130
Yes, I agree we need Ed25519 and from the discussions on those issues, unfortunately, it seems .NET won't provide it. And even if it did, it wouldn't be supported on Windows.
I’m assuming the aim is to avoid any dependencies? That’s perfectly fine I just wanted to double check.
Yes, I'd like to avoid dependencies, but it may be preferable to doing own crypto.
I don't know yet how to go about the Ed25519 support, but let's set a target for the end of August.
Let's use Bouncy Castle (https://github.com/bcgit/bc-csharp) for implementing this.
I have no idea what the landscape is in .NET for cryptography libraries but NSec seemed to be another decent alternative.
Bouncy Castle is well known. It is all managed code, and has not other dependencies.
For NSec, there is a dependency on a native library (libsodium) which is something I'd like to avoid.
This is part of 0.6.0 which was just uploaded to nuget.org.
Issue to track support for ED25519 private keys. I'm unsure what effort is involved to actually support this key type but as it's the recommended type used today for SSH supporting it in this library would be good.