对称加密算法在C#中的踩坑日常

前言

有幸接触了一下传说中的对称加密算法3DES

感觉这些加密算法与我的工作是想去甚远的,一般没什么机会接触这些东西

今次了解了一下3DES这个对称算法

原理算不上明白,算是踩了C#中的一些坑吧

C#中对于密钥的处理比较奇怪,花费了一晚上一早上的时间才弄明白

期间偷窥了不少C#的源代码

下面由我娓娓道来

简介

3DES算法命名

定义算法最早期的标准被放在ANS X9.52中并在1998年发布并将其描述为三重数据加密算法(简称TDEA),在ANSI X3.92中定义了该算法的三个操作但是并没有使用DES或者3DES,直到1999年发布的FIPS PUB 46-3在正式命名三重数据加密算法,大概在2004到2005的样子才正式引入三重数据加密算法,之前一直以TDEA存在着,也就是说TDEA就是3DES,但是没有使用3DES作为标准术语。

基本逻辑

三重数据加密算法使用包括密钥K1,密钥K2和密钥约束K3,每一个包含56位不包含奇偶校验,算法实现公式如下:

ciphertext = EK3(DK2(EK1(plaintext)))

密文 = EK3(DK2(EK1(平文)))

用K1对数据进行加密,用K2对数据进行解密,用K3对数据再加密。

解密公式为如下:

plaintext = DK1(EK2(DK3(ciphertext)))

平文 = DK1(EK2(DK3(密文)))

用K3j对数据进行解密,用K2对数据进行加密,用K1对数据进行加密。每次加密都处理64位数据并形成一块。

3DES加密选项

定义了三种密钥选项。

(1)三个密钥相互独立。

(2)K1和K2密钥独立,但K1 = K3。

(3)三个密钥相等。

密钥选项1的强度最高,拥有3 x 56 = 168个独立的密钥位。

密钥选项2的安全性稍低,拥有2 x 56 = 112个独立的密钥位。该选项比简单的应用DES两次的强度较高,即使用K1和K2,因为它可以防御中途相遇攻击。

密钥选项3等同与DES,只有56个密钥位。这个选项提供了与DES的兼容性,因为第1和第2次DES操作相互抵消了。该选项不再为国家标准科技协会(NIST)所推荐,亦不为ISO/IEC 18033-3所支持。

C#实现

讲真简介里用来凑字数的这些内容我其实没怎么看明白

C#中使用TripleDESCryptoServiceProvider类来实现相关功能

        public static string DesEncrypt(string input, string key)
        {
            byte[] inputArray = Encoding.UTF8.GetBytes(input);
            TripleDESCryptoServiceProvider tripleDES = new TripleDESCryptoServiceProvider();
            tripleDES.Key = Encoding.UTF8.GetBytes(key);

            tripleDES.Mode = CipherMode.ECB;
            tripleDES.Padding = PaddingMode.PKCS7;
            ICryptoTransform cTransform = tripleDES.CreateEncryptor();
            byte[] resultArray = cTransform.TransformFinalBlock(inputArray, 0, inputArray.Length);
            tripleDES.Clear();
            return Convert.ToBase64String(resultArray, 0, resultArray.Length);
        }

        public static string DesDecrypt(string input, string key)
        {
            byte[] inputArray = Convert.FromBase64String(input);
            TripleDESCryptoServiceProvider tripleDES = new TripleDESCryptoServiceProvider();
            tripleDES.Key = Encoding.UTF8.GetBytes(key);
            tripleDES.Mode = CipherMode.ECB;
            tripleDES.Padding = PaddingMode.PKCS7;
            ICryptoTransform cTransform = tripleDES.CreateDecryptor();
            byte[] resultArray = cTransform.TransformFinalBlock(inputArray, 0, inputArray.Length);
            tripleDES.Clear();
            return Encoding.UTF8.GetString(resultArray);
        }

从下面源码中看出,该类接收的Key为16位或24位

然后对于这个Key,C#似乎有自己的处理方式

以下为个人理解:

这个24位的key会被处理成3个8字节的独立密钥参与运算

当提供24位key时并没有什么不妥

但是当提供16位的key时 会把提供的key拆分成两个块(block) 并以第一个块作为第三个块组成一个24位的密钥

如下:

输入密钥:49, 50, 51, 52, 53, 54, 55, 56, 57, 49, 50, 51, 52, 53, 54, 55

实际使用:49, 50, 51, 52, 53, 54, 55, 56, 57, 49, 50, 51, 52, 53, 54, 55, 49, 50, 51, 52, 53, 54, 55, 56

可以看出使用了前8位来进行后面8位的补全

这时候你可能要问,如果提供一个不是16位也不是24位的密钥时会发生什么

会抛异常

以上理解都是在.NetFramework中的体现

如果换到NetCore中,效果就又不一样了

NetCore

在NetCore中不存在TripleDESCryptoServiceProvider 取而代之的是 TripleDES

所以此时我们的代码需要稍作修改

public static string DesEncrypt(string input, string key)
        {

            byte[] inputArray = Encoding.UTF8.GetBytes(input);
            var tripleDES = TripleDES.Create();
            var byteKey = Encoding.UTF8.GetBytes(key);
            tripleDES.Key = byteKey;
            tripleDES.Mode = CipherMode.ECB;
            tripleDES.Padding = PaddingMode.PKCS7;
            ICryptoTransform cTransform = tripleDES.CreateEncryptor();
            byte[] resultArray = cTransform.TransformFinalBlock(inputArray, 0, inputArray.Length);
            return Convert.ToBase64String(resultArray, 0, resultArray.Length);
        }

        public static string DesDecrypt(string input, string key)
        {
            byte[] inputArray = Convert.FromBase64String(input);
            var tripleDES = TripleDES.Create();
            var byteKey = Encoding.UTF8.GetBytes(key);
            tripleDES.Key = byteKey;
            tripleDES.Mode = CipherMode.ECB;
            tripleDES.Padding = PaddingMode.PKCS7;
            ICryptoTransform cTransform = tripleDES.CreateDecryptor();
            byte[] resultArray = cTransform.TransformFinalBlock(inputArray, 0, inputArray.Length);
            return Encoding.UTF8.GetString(resultArray);
        }

NetCore中同样要求我们提供24位的Key

但是不在兼容16位的Key,如果你提供一个非24位的Key就会异常

不过没关系,对于16位的Key我们可以自行处理一下

同理使用前8位补全后8位

        public static string DesEncrypt(string input, string key)
        {

            byte[] inputArray = Encoding.UTF8.GetBytes(input);
            var tripleDES = TripleDES.Create();
            var byteKey = Encoding.UTF8.GetBytes(key);
            //复制前8位补全后8位
            byte[] allKey = new byte[24];
            Buffer.BlockCopy(byteKey, 0, allKey, 0, 16);
            Buffer.BlockCopy(byteKey, 0, allKey, 16, 8);
            tripleDES.Key = allKey;
            tripleDES.Mode = CipherMode.ECB;
            tripleDES.Padding = PaddingMode.PKCS7;
            ICryptoTransform cTransform = tripleDES.CreateEncryptor();
            byte[] resultArray = cTransform.TransformFinalBlock(inputArray, 0, inputArray.Length);
            return Convert.ToBase64String(resultArray, 0, resultArray.Length);
        }

        public static string DesDecrypt(string input, string key)
        {
            byte[] inputArray = Convert.FromBase64String(input);
            var tripleDES = TripleDES.Create();
            var byteKey = Encoding.UTF8.GetBytes(key);
            //复制前8位补全后8位
            byte[] allKey = new byte[24];
            Buffer.BlockCopy(byteKey, 0, allKey, 0, 16);
            Buffer.BlockCopy(byteKey, 0, allKey, 16, 8);
            tripleDES.Key = allKey;
            tripleDES.Mode = CipherMode.ECB;
            tripleDES.Padding = PaddingMode.PKCS7;
            ICryptoTransform cTransform = tripleDES.CreateDecryptor();
            byte[] resultArray = cTransform.TransformFinalBlock(inputArray, 0, inputArray.Length);
            return Encoding.UTF8.GetString(resultArray);
        }

至此就可以正常兼容NetFramework的代码了

小结

至此写下此文,也算是对3DES有了些许了解吧

需要记住

在.NET Core中利用3DES加密和解密必须要给出3个密钥即24个字节即使密钥3和密钥1相等,它不会像.NET Framework中会重用密钥1中的位数。

原文地址:https://www.cnblogs.com/ixysy/p/11057807.html

时间: 2024-10-11 03:39:43

对称加密算法在C#中的踩坑日常的相关文章

记录某项目中的踩坑与解决(持续更新)

前言 最近参加了某个比赛, 我所选的赛题就是个类似知乎这样的安卓app,由于着手近一个月了,踩了不少坑,之前没怎么记录,估计事后也会忘记干净. 因此特开一帖,在此记录下相关的坑. 记录 写完某个Recyclerview的item布局和相关适配器后, 然后展示的时候, 发现显示出来的Item数量小于List中绑定的数据量: 首先是检查了一遍适配器中的逻辑,发现没啥问题.然后在onCreateViewHolder中打log,发现只创建了两次就没了(而实际应该创建6次). 最后百度才发现是外面的Scr

webpack 1.x升级过程中的踩坑总结大全

错误:Error: Chunk.entry was removed. Use hasRuntime() 卸载npm uninstall extract-text-webpack-plugin --save-dev 重新下载 npm install [email protected]^2.0.0-beta.4 错误:Error: Breaking change: extract now only takes a single argument. 原因是webpack2对loader的配置做了一些调

Java 加密解密之对称加密算法AES

Java 加密解密之对称加密算法AES 密码学中的高级加密标准(Advanced Encryption Standard,AES),又称Rijndael加密法,是美国联邦政府采用的一种区块加密标准.这个标准用来替代原先的DES,已经被多方分析且广为全世界所使用.经过五年的甄选流程,高级加密标准由美国国家标准与技术研究院 (NIST)于2001年11月26日发布于FIPS PUB 197,并在2002年5月26日成为有效的标准.2006年,高级加密标准已然成为对称密钥加密中最流行的算法之一.该算法

项目管理如何才能不踩坑?

在项目管理过程中,由于需求的变化,项目总是具有不确定性.易变性,踩坑对于项目管理工作者来说是家常便饭,甚至可以说,项目管理工作者的大部分工作时间都是在填坑. 项目频繁掉"坑",抱怨和撂挑子只能爽一时,后续该做的事同样一个都跑不了.积极面对.冷静分析.借助资源和工具才是正确的应对方法.等你把遇到的坑都成功填上,你会发现,你的填坑力其实就是你的竞争力.下面就跟大家分析一些项目管理过程中常见的"坑",以及如何避免"踩坑". 一.项目管理有哪些坑? 项目

Android NDK中的C++调试踩坑标记

RT, Android NDK中的C++调试, GDB调试比较麻烦,在ADT Eclipse中: 1.配置好NDK给工程加上Native Support 2.编译中加上NDK_DEBUG=1 3.然后改造下mk文件: #APP_DEBUG will be set by android-ndk if NDK_DEBUG=1 is set. ifdef APP_DEBUG ifeq ($(APP_DEBUG),true) CFLAGS+= -O0 -g LOCAL_CFLAGS+= -D_DEBUG

cocos creator踩坑日记(持续更新中...)

踩坑一 问题:项目在构建成Web Mobile后运行在浏览器和微信中,点击页面任何地方都会导致自动全屏 解决:在构建之后的main.js中,去掉 cc.view.enableAutoFullScreen(true) 踩坑二 问题:精灵使用move to后路径上会留下一些线条 原因:脏矩形出问题了 解决: Canvas模式下才有脏矩形,使用这个方法之前要判断 if (cc._renderType === cc.game.RENDER_TYPE_CANVAS) { cc.renderer.enabl

阿里云磁盘扩容踩坑总结

公司半年前上线一个新的项目,采购了一批阿里云主机,磁盘组成是40G系统盘+100G的数据盘,数据库采用MariaDB Galera Cluster集群部署,由于业务数据量快速增长,导致磁盘存储空间剩余量很少,急需要扩容,先总结整个项目规划中埋下的坑: 1.没有DBA对数据库的容量规划,而前期的运维人员采购时选用100G的SSD云盘: 2.数据库默认使用共享表空间,缺点是删除数据后不释放空间,当数据快速增长后,我们采取了先删除临时表数据的方式来尽量避免暴力扩容,争取在春节期间稳定,删除部分数据后,

Android开发在路上:少去踩坑,多走捷径【转】

作者:gzjay,腾讯MIG无线产品部 高级工程师 最近一朋友提了几个Android问题让我帮忙写个小分享,我觉得对新人还是挺有帮助的,所以有了这个小分享. 1.目前, Android APP开发完成后,通常需要在哪些机型上进行测试? 2.目前, 开发Android APP时,需要考虑的分辨率有哪些? 这两个问题可以合起来回答的. http://developer.android.com/about/dashboards/index.html 源自Google Play的数据,每月都会进行upd

vue+ vue-router + webpack 踩坑之旅

说是踩坑之旅 其实是最近在思考一些问题 然后想实现方案的时候,就慢慢的查到这些方案   老司机可以忽略下面的内容了 1)起因  考虑到数据分离的问题  因为server是express搭的   自然少不了res.render("xx",data)    这句话的意思就是去查找相应的模板文件然后在用数据去渲染在将渲染好的页面去返回给浏览器,给浏览器去解析,渲染模板其实就是做的替换字符串+拼接字符串的活  各种的模板引擎也有各个优化的点(比如可以将对应的模板编译的函数保存在内存中,然后在通