Closed DeltaJordan closed 6 years ago
I wrote that DLL in C. Almost never use C++ if i dont have to. And I did it primarily because C#'s default crypto lib is trash and 20 years behind. Essentially i need an AES engine to handle XTS and CTR
Also i'd wish you didnt change the indent style I use. :cry: That aside, I think 2 projects is more of a con. But I also havent looked into what libs arent supported. Could also just make the mono one a single project and keep it on its own branch.
I'll fix the style, my bad. I'm just used to the standard style set by Visual Studio. As for putting it on its own branch, if you want I can watch this repo and pull request changes you make on the master branch onto the mono branch. Also if you could give me access to the source of NXCrypt.dll I can either attempt to port it or find a suitable library to use.
That'd probably be the best idea. A lot of software does it that way anyways. Skype for example. Anyways my dll code is hacky.. but here: https://reisyukaku.org/downloads/xts.zip Edit: I added a mono branch, i think you have to click things on your end to redirect the PR there.
Uh this is not done yet, I'm still in the process of implementing AES 128 XTS, CTR, and ECB to handle the switch crypto.
That's fine. You PR'd it so I assumed you wanted it in the upstream. lol When its in working condition, a release can be made thought.
This is a preemptive addition. A few issues with fully implementing this is preventing me from completing the mono support.
Mono cannot use P/Invoke (DllImport), and NXCrypt.dll, most likely a C++ library, is needed for the application. (I already added an existing NuGet library to read and write ini files)
Proposed solutions:
Need a future-proof way to implement Mono, ideally the easiest way to implement future changes and still support Mono.
Proposed solutions:
Use a separate project
Use one project that supports Mono