0宽字符加密_AES字节数组加密解密流程

AES类时微软MSDN中最常用的加密类,微软官网也有例子,参考链接:https://docs.microsoft.com/zh-cn/dotnet/api/system.security.cryptography.aes?view=netframework-4.8
但是这个例子并不好用,限制太多,通用性差,实际使用中,我遇到的更多情况需要是这样:
1、输入一个字节数组,经AES加密后,直接输出加密后的字节数组。
2、输入一个加密后的字节数组,经AES解密后,直接输出原字节数组。

对于我这个十八流业余爱好者来说,AES我是以用为主的,所以具体的AES是怎么运算的,我其实并不关心,我更关心的是AES的处理流程。结果恰恰这一方面,网上的信息差强人意,看了网上不少的帖子,但感觉都没有说完整说透,而且很多帖子有错误。

因此,我自己绘制了一张此种方式下的流程图:

987be9ac8e34eb56738ebb7ee14a54f2.png

字符串在加密后,长度会变长。如果数组长度为16的倍数,则加密后的数组长度=原长度+16;如果数组长度不为16的倍数,则加密后的数组长度=16倍数向上取整。

按照此流程图进行了核心代码的编写,验证方法AesCoreSingleTest既是依照此流程的产物,实例化类AesCoreSingle后调用此方法即可验证。

至于类中的异步方法EnOrDecryptFileAsync,则是专门用于文件加解密的处理,此异步方法参考自《C# 6.0学习笔记》(周家安 著)最后的示例,这本书写得真棒。

但我也有疑惑,为什么周家安的异步方法,就不用考虑字符串加密前后长度变化的问题呢?

class 
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值