search

maythamfahmi / CryptoNet

CryptoNet is simple, fast and a lightweight asymmetric and symmetric encryption library.
https://github.com/maythamfahmi/CryptoNet
MIT License
101 stars 19 forks source link

[feature request]: Add secure key storage and retrieval. #82

Open maythamfahmi opened 1 month ago

maythamfahmi commented 1 month ago

Contact Details

No response

Is your feature request related to a problem? Please describe.

Add secure key storage and retrieval.

Describe the solution you'd like

Add secure key storage and retrieval.

Describe alternatives you've considered

No response

Additional context

No response

Priority Level

Medium

Code of Conduct

maythamfahmi commented 2 weeks ago

@jwdonahue any suggestion how to approch this? as you have suggested this feature.

jwdonahue commented 2 weeks ago

If there isn't an existing portable, secure key storage scheme, then we should design one. More research required. I think I stopped looking when the one thing I originally thought might work, turned out to be a Windows only kind of thing.

Requirements:

  1. Dotnet 8+ (portable), preferably C#, but C++ with a C# native library wrapper would be acceptable..
  2. Salted + Encrypted at rest.
  3. Secure RAM/Flash, where available, when not at rest.
  4. Optional USB key support.

I am not a trained security expert, so we should try to enlist one of those, if possible. I am fairly good at doing research, and this is an area I am interested in, but I am sure I can find as many ways to screw it up as get it right. There's probably lots of patent pitfalls in this area as well.

  1. Some kind of cloud support (Azure/AWS) is probably a good idea, but it should absolutely allow for local, non-cloud/subscription support.
jwdonahue commented 2 weeks ago

It's been years since I did a deep dive, but my recollection is that there are different levels of hardware support, for key storage and encryption schemes, across all the dotnet platforms. We should survey what is out there now, and if we can't find support for all five of those requirements, we should see if it would not be possible to come up with a reasonable interface/abstraction, and then start implementing for each target (if that's what is required).

jwdonahue commented 2 weeks ago

To be clear, either we do it the right way, or remove all private key storage and retrieval bits from the code base. We should NOT promote any kind of insecure private key storage or exchange mechanisms. The library may be useful enough by simply encapsulating some of the common encryption mechanisms.

maythamfahmi commented 2 weeks ago

The question is like any other secret management, is it the libaray responsiblit to take care of secret? in real world I would not save secret as plan text, I would consider saving it in key vault. With that said, if you have idea come with it and we see how we could approch it. I was thinkin we are already having an AES encryption, we could use the libaray our encryption to encrypt own key. but buttom line some one need to remember the secret of encrypiton and decryption.