我需要对ASP.NET Core应用程序中的某些数据进行大量加密。
这个想法是： 用户将拥有哈希密码。用户还将拥有非对称密钥（RSA-512）。公钥存储在DB中。私钥首先通过对称密钥（AES-256）加密。作为此加密的关键，我们使用用户的普通/文本密码。
如果我想创建一些汽车实体的例子。我将为这个特定的汽车实体生成公钥和私钥。公钥以纯文本格式存储。私钥使用“car”（用户）的创建者的公钥加密。
属于汽车的字段不是用汽车的公钥加密的。
解密汽车。我们需要用户的私钥，因为这需要解密汽车的私钥。通过这个解密的汽车私钥，我们可以解密汽车的内容。
但要成为用户的私钥，我需要使用普通/文本密码对其进行解密。此密码仅在@登录时间后可用（它无处存储）。
我现在遇到的问题是我使用的是带有IdentityServer 4的联合登录系统。这是一个与我的API项目不同的“项目”。
但是我需要API中的密码，因为这会执行我的“业务逻辑”。
真正的问题在这里开始：
解决这个问题：
我在考虑在我的API中添加一个“路由”，我的登录项目可以调用它。 因此，每次用户登录登录项目时，都会执行对正确API的REST调用，并显示以下消息：'这是用户X的私钥的解密版本。
此时，API会将其存储在“InMemory”EF Core数据库中。每次用户需要解密他的汽车数据。我需要从'InMemory'DB中检索私钥。
问题我在这里。 EF'InMemory'数据库是否用于此目的？看起来它只用作演示或测试目的。
何时删除内存的私钥。如果用户注销我可以管理它。但是当用户“过期”时，我无法触发此操作。所以他的解密私钥将继续留在记忆中。
'InMemory'数据库的可靠性如何？什么时候“清理”自己？
我很高兴收到一些有用的提示。
此致Brecht
答案 0 :(得分：1)
除了安全问题（请参阅注释）之外，InMemoryDatabase主要用于测试或无dbs教程。你添加到它的所有东西都会保留到deleted（有时候垃圾收集，你实际上无法控制！）或DbContext被处理掉。
使用内存缓存（分布式或本地）更有意义，而不是InMemory EF核心数据库。
您当然可以使用像Redis这样的分布式缓存，并保护其中已解码的私钥，并从您的服务中调用它。您可以添加expiry日期，当密钥失效并需要通过调用密钥上的expire command来请求或延长过期时间时，当用户注销时，请使用{{3}删除密钥}。
如果您扩展服务器，它也可以正常工作。如果从Microsoft.Extensions.Caching.Memory开始，您可以稍后轻松切换到Redis，因为它们都实现了IDistributableCache接口，只需更改启动类中的配置。
您也可以尝试使用SecureString（请参阅del），它不是直接在.NET Core中实现，而是作为额外的包here提供），以尽可能缩短它在本地内存中，不要依赖GC在某些时候执行此操作。