[feature request]: Implement DSA algorithm

[maythamfahmi]

https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.dsa.create?view=net-6.0

[maythamfahmi]

Not sure yet, but condering moving it to be part of extension package for CryptoNet

[jwdonahue]

I don't understand the purpose of the extension package. Last time I looked, there were no extension methods in that assembly.

[maythamfahmi]

@jwdonahue the whole idea was that I wanted to introduce som extension methods in a seperate package lets for now call it crypto net extension pack. so the current extension will be reused in extension package. There are some re-thinking of archecture I need to do. So it might change a bit. I am not 100% sure yet.

[jwdonahue]

Reasons to have a separate assembly in your library package:

• Isolate rapidly changing code from stable code.
  -- Written once, compiled once.
• Code may be packaged and consumed separately from other code.
• Organize source file proliferation.
  -- Note that using folders for this, has less impact on build and run times.
• Performance:
  -- Avoid loading the bits in use cases where the code is not needed.
  -- Avoid having to load the bits earlier than they are needed.
  -- Speed up build times.
  --- Use cached/pre-built assembly to avoid building stable code for every pull request.
  --- This is often ignored for units of code that have fast build/test times, where the extra effort required to adapt the build isn't always seen as a high priority.

Reasons not to have a separate assembly in your library package:

• Avoid file proliferation.
• • Every binary should be independently versioned, and that just adds to build complexity.
• Performance:
• • The code is always used early in the execution paths of its dependents.
• • File system latency is fixed and higher than the size of the assembly warrants.
• Naming things is hard ;)

Reasons to have a separate package:

• Code is self contained and useful by itself.
• Code is maintained by different team from other bits.
• Code is published on a different cadence from other bits.
• License or other legal reasons.
• Marketing.

Reasons not to have a separate package:

• It complicates dependency management.
  -- Deep and complicated dependency graphs, can add constraints on the order of package construction.
  -- Avoid the deadly diamond of death!

I probably missed more than a few.

I am sure that I have ignored every one of those ideas, at one time or another, for one arbitrary reason or another. I think sometimes maybe I just happen to come up with a good name for some collection of bits and want to apply it to them. In other words, it can be a matter of taste.

[maythamfahmi]

Thanks for sharing

Main reason

Cryptonet using .net standard 2 for compatibility reasons.
While extension pack has some helpers methods that require. Net 8.0.

I am working on feature #127 it is getting a better form with refactoring of naming and moving stuff. Still not finished but with couple of days I think will be done.

[jwdonahue]

I use conditional compilation for those bits.

I have have this in most of my solution folder's Directory.Build.Props file:

preview true net8.0;net9.0 enable enable true $(SolutionDir)={SHLLC/CoreLibs/$(SolutionName)}/

I use conditional compilation. For instance, this little gem:

#if NET9_0_OR_GREATER
    private static readonly Lock _lock = new();
#else
    private static readonly object _lock = new();
#endif

[jwdonahue]

Extensions is a C#-ism:

int ExtensionMethod(this object) ...

Hence my confusion around the extension assembly.

[jwdonahue]

I've also dropped support for everything below Net8 in my own projects.