数据安全往往是开发人员很容易忽略的一个部分，包括我自己。近两年业内也出现了很多因为安全问题导致了很多严重事情发生，所以安全对我们开发人员很重要，我们要对我们的代码的安全负责。
在工作中，我们常常会见到 encode，base64，sha256, rsa, hash，encryption, md5 等，一些人对他们还傻傻分不清楚，也不知道什么时候使用他们，还有一些人认为MD5就是加密算法。
在 ASP.NET Core 中，为数据保护相关提供了一批新的 API，包括加密解密机制，下面就让我们来看看吧。
目录
•加密，编码，哈希之间的区别
•数据保护（Data Protection）介绍
•ASP.NET Core 中的数据保护
•总结
编码，加密，哈希之间的区别
1、编码
编码是信息从一种形式或格式转换为另一种形式的过程，他们是可逆的。
如 url、base64、jsunicode、utf-8等等。
2、加密
加密是可逆的，类似于编码也是把数据从一种形式转换为另一种形式，它通过一个特定的加密的密匙，相对应的有解密的过程。加解密的算法有2种：对称加密算法和非对称加密算法。
对称：DES、AES、SM1、RC4 等等。
非对称：RSA、ECC、SM2 等等。
3、哈希
又叫"散列"，就是把任意长度的数据转换成固定长度的“指纹”，这个过程是不可逆的。而且只要输入发生改变，输出的 hash值也会有很大不同。
它还有一个特性是相同的输入总是有相同的结果, 这种特性恰好合适用来用来保存密码。
如：MD5、SHA256, SHA512, RipeMD, WHIRLPOOL等等。
数据保护（Data Protection）介绍
在看数据保护官方文档的时候，微软的文档是这样写的，大致意思就是他们基于几点需求，要开发一套数据保护的库以便用来给受信任的客户端和不受信任的客户端来使用。这几点要求就是：
1、真实性、完整性
举了一个身份验证cookie的例子，就是服务端生成了一个包含xyz权限的token，然后会在将来的某个时间过期，这个时候就需要重新请求生成一个，怎么样来保证请求的token不是被篡改过的。
2、机密性
服务器要保证请求是受信任的，所以就需要一些包含特定操作环境的信息，比如一个路径，一个权限或者一个句柄或者其他的一些东西特定于服务器的东西，这些信息不应该透漏给不受信任的客户端，也就是说类似于私钥。
3、隔离性
然后就是要求做成一个组件，并且这个组件具有独立性，可以不依赖于系统中的其他组件。如一个bearer token的组件，它要使用这个组件的话，也不需要引用anti-CSRF这种机制了。
再进一步的缩小需求范围，加密的数据不需要在系统之外的其他系统中使用，另外处理速度要尽可能的快，因为每一次web请求都会使用加密组件一次或者多次。
基于以上要求，微软提出来可以使用密码学，因为这是一个典型的密码学应用的场景。确实这是一个密码学的应用场景，并且是一个非对称加密算法的场景。但是大家都知道，非对称加密是由一个公钥和私钥用来保证安全性的，即使公钥遭泄露，整个通讯仍然是安全的，这就是它比对称加密的好处。但是非对称加密也是有缺点的，就是加密和解密花费的时间长，速度慢。
但是上面的要求又是需要速度尽可能快，怎么办呢？ 于是微软的工程师们想出了可以通过精简并且优化非对称加密机制，来达到这个要求。因为不需要跨系统或者跨语言什么的，所以也不需要什么协议之类的，这就给优化带来了更多的可能性。
到这里，我就想，如果让我来基于以上几点来设计开发这样一个系统，我应该怎么样设计？怎么样达到要求？
带着这个问题，我们来进一步看看微软是怎么样做的吧？
下面是一些总结的设计原则 ：
1、配置应该尽量的简单，默认情况下应该可以零配置，开发人员可以直接运行。
2、提供一个简单的API，应该容易使用，并且不会轻易用错。
3、开发人员不需要专门学习怎么样管理这些钥（公钥，私钥），系统应该自动的选择算法和管理钥的生命周期。理想情况下开发人员都不应该访问这些钥的原始文件。
4、钥应该是受保护的，不会被远程调用到。系统应该有一个自动保护机制并且可以自动应用。
如果让我设计这样一个库，我可能不会想到这么多，也许只会想到前3点。
再看一下针对的受众群体：
1、应用程序开发人员和框架开发人员（不需要学习任何知识）。
2、应用开发人员和系统管理员（不使用默认配置，只是设定一些路径等）。
3、针对具有更高安全意识的开发人员提供可扩展api，或特定需求扩展（需要重写系统的组件，有一些独特的需求）。
以上，可以看到微软在开发一个组件的时候对问题的分析，也许我们可以从中学到一些东西。
ASP.NET Core 中的数据保护