【信息安全课程实验报告】3DES加解密算法

【信息安全课程实验报告】3DES加解密算法

信息安全课程实验报告

Java源代码

文章目录

1.实验目的

1.1实验要求1.2实验任务1.3实验内容 2.实验原理以及应用

2.1实验原理2.2实验背景 3.实验步骤

3.1实现DES加解密算法3.2实现3DES加解密算法3.3设计UI界面 4.实验结论和问题解答

4.1实验结论4.2问题解答 5.实验体会

1.实验目的 1.1实验要求

1.编程实现DES加密和解密算法，并使用DES加解密算法实现3DES加解密算法
2.选择一种填充方式，对需要加密的文件进行填充（解密要去掉填充部分）。
3.DES的加解密的工作模式，采用密码分组链接（CBC）模式
4.读取/写入被加密/解密文件时，采用字节流的形式进行文件读取/写入
5.完成实验后，需要交实验报告（包括：重要函数的功能分析和流程图）

1.2实验任务

基于3DES加解密算法，编程实现对任意文件实现加解密的小软件。

1.3实验内容

1.掌握DES算法的原理及过程
2.完成DES密钥扩展运算
3.完成DES数据加解密运算
4.基于已经实现的DES模块进一步实现3DES加解密算法
5.对3DES实现最后一个分组填充（本文采用全零填充方式）
6.3DES的加解密的分组工作模式，采用密码分组链接（CBC）模式
7.实现用户UI界面，方便用户使用
8.进行加解密测试，验证代码正确性

2.实验原理以及应用 2.1实验原理

明文M，密文C，密钥k1，k2和k3，加密算法E解密算法D。3DES算法的过程可表示为：加密：C=Ek3(Dk2(Ek1(M))) 即对明文数据进行，加密，解密，加密的顺序过程，最后得到密文数据解密：M=Dk1(Ek2(Dk3©)) 即对密文数据进行，解密，加密，解密的顺序过程，最后得到明文数据。k1可以等于k3，但不能三个密钥均相等（如果相等的话就成了DES算法了，减弱了3DES的安全性）。3DES可以是3DES-CBC，在原来的加密或者解密处增加了异或运算的步骤，用来提高算法的安全性。
3DES使用3个8字节长度（64位二进制）的密钥，即k1，k2，k3，然后进行加密运算和解密运算。3DES（K1≠K2≠K3），在3DES加密时，对加密——解密——加密依次使用密钥1、密钥2、密钥3，在3DES解密时对解密加密解密依次使用密钥3、密钥2、密钥1。由于DES加解密算法是每8个字节作为一个加解密数据块，因此在实现该算法时，需要对数据进行分块和补位 *** 作(即最后不足8字节时，要补足8字节，本文采用全零填充)。 3DES的CBC工作模式：将待处理的数据分组，但是每一组数据在加密或者解密之前都要与前一块的结果做一次异或 *** 作。该模式需要定义一个特殊的8字节初始化向量IV，用于和第一组数据进行异或 *** 作。注意IV参数是对应CBC模式的。这样一来，每一组数据都是有联系的，并且增加了一个随机变量IV更加可以提高算法的安全性。

2.2实验背景

在DES中,初始置换IP和初始逆置换IP-1各使用一次，使用这两个置换的目的是为了把数据彻底打乱重新排列。它们对数据加密所起的作用不大，因为它们与密钥无关且置换关系固定,所以一旦公开,它们对数据的加密便无多大价值。
在DES算法加密过程中除了S盒是非线性变换外，其余变换均为线性变换。因此S盒是DES算法安全的关键。任意改变S盒输入中的一位，其输出至少有两位发生变化。由于在DES中使用了16次送代，所以即使改变明文或密钥中的1位，密文中都会大约有32位发生变化。S盒的设计原则一直没有完全公开。经过多年来的研究，人们的确发现了S盒的许多规律，但至今还没有发现S盒的致命缺陷。
由于DES算法是公开的,因此其安全性完全依赖于所用的密钥（符合柯克霍夫原则，即密码体制的安全性不应依赖加密算法的保密性，而应取决于可随时改变的密钥）。在算法使用过程中，每次迭代时都有一个子密钥供加密使用。子密钥的产生也很有特色，它确保密钥中各位的使用次数基本相等。大量实验表明,56位密钥中每位的使用次数在12次至15次之间。在实际使用中,需要注意的是DES算法存在一些弱密钥。所谓弱密钥是指一个密钥产生的所有子密钥都是相同的，此时对消息加密两次就可以恢复出明文。虽然DES算法有弱密钥现象，但是弱密钥所占比例很小，可以在选取密钥时避开使用，因此对其安全性影响不大。
随着密码分析技术和计算能力的提高DES的安全性受到质疑和威胁。密钥长度较短是DES的一个主要缺陷。DES 的实际密钥长度为56位，密钥量仅为256≈1017,就目前计算设备的计算能力而言,DES不能抵抗对密钥的穷举搜索攻击。1998 年7月，电子边境基金会(EFF)使用台价值 25万美元的计算机在56小时内成功地破译了DES。在1999年1月，电子边境基金会(EFF)仅用22小时15分就成功地破译了DES。
因此使用3DES代替DES提高算法的安全性。3DES（或称为Triple DES）是三重数据加密算法（TDEA，Triple Data Encryption Algorithm）分组密码的通称。它相当于是对每个数据分组应用三次DES加密算法。由于计算机运算能力的增强，原版DES密码的密钥长度变得容易被暴力破解；3DES即是设计用来提供一种相对简单的方法，即通过增加DES的密钥长度来避免类似的攻击，而不是设计一种全新的分组密码算法。
3DES中的key1，key2，key3决定了算法的安全性，若三个密钥互不相同，本质上就相当于用一个长为168位的密钥进行加密。多年来，它在对付强力攻击时是比较安全的。若数据对安全性要求不那么高，key1可以等于key3。在这种情况下，密钥的有效长度为112位。
3DES，也称为 3DESede 或 TripleDES，是三重数据加密算法，相当于是对每个数据应用三次DES的对称加密算法。由于DES密码长度容易被暴力破解，所以3DES算法通过对DES算法进行改进，增加DES的密钥长度来避免类似的攻击，针对每个数据块进行三次DES加密；因此，3DES加密算法并非什么新的加密算法，是DES的一个更安全的变形，它以DES为基本模块，通过组合分组方法设计出分组加密算法。
3DES是DES向AES过渡的加密算法，它使用2个或者3个56位的密钥对数据进行三次加密。相比DES，3DES因密钥长度变长，安全性有所提高，但其处理速度不高。因此又出现了AES加密算法，AES较于3DES速度更快、安全性更高。

3.实验步骤

对本文3DES加解密算法的几点说明：
1.DES算法通过读入64位二进制密钥和一个标志加解密的标志对读入64位二进制输入（明文或者密文）进行加解密 *** 作。
2.3DES使用3DES-CBC模式：该模式中共使用3个不同密钥，依次用加密—解密—加密。
3.3DES使用全零填充和CBC工作模式。
4.3DES所需要的3个密钥k1，k2，k3和一个初始化向量IV均可以由用户设置（以16位16进制的形式）。

3.1实现DES加解密算法

DES是一个分组加密算法，它以64位二进制为一个分组对数据加密。64位一组的明文从算法一端输入，得到长度相等的64位密文从另一段输出。DES是一个对称算法:加密和解密用的是同一个算法。
密钥通常表示为64位二进制数，但每个第8位都用作奇偶校验，可以忽略，所以密钥长度为56位。密钥可以是任意的56位的数，且可在任意的时候改变。
对于任意的加密方案，总有两个输入:明文和密钥。DES 的明文长为64位，密钥长为
56位。明文的处理一般经过三个阶段: 首先， 64位的明文经过初始置换(IP) 而被重新排
列。然后经历16 轮函数的作用，每轮作用都有置换和替代。最后一轮迭代的输出有64位，它是输入明文和密钥的函数。其左半部分和右半部分互换产生预输出。最后预输出再被与初始置换(IP)互逆的置换产生64位的密文。
DES算法的本质是将加密的两个基本技术——混淆和扩散的组合在一起，先替代后置换。通过P盒和S盒完成置换和替代工作，其中S盒是DES唯一的非线性结构。
本文DES算法，首先将16进制16位的数组转换成64位二进制字符数组，然后根据子密钥生成的规则生成子密钥并保存以便后来使用；最后在进行初始置换之后进行16轮运算，再进行初始逆置换得到最终结果。DES算法的主流程图如图1所示；子密钥生成流程图如图2所示；轮函数f的流程图如图3所示。

DES算法核心代码如图4,5,6,7所示。

3.2实现3DES加解密算法

首先对3DES函数的输入和输出进行说明：3DES要求输入待处理的文件路径（包括加解密），输出结果文件路径，一个64位字符数组表示的二进制初始化向量IV，三个64位字符数组表示的二进制密钥key1，key2，key3，以及一个加解密标志flag。3DES的输出的生成结果文件。如果是加密生成的结果文件路径用Epath存储，如果是解密生成的结果文件路径用Dpath存储。
3DES完成了对文件字节流的处理，全零填充和CBC分组工作模式。3DES算法核心代码如图8,9,10所示；3DES流程图如图11所示；3DES的核心代码如图12，13，14所示。

对图进行简要说明，Java提供了直接将文件按字节流形式读入的函数，这样可以直接将文件的字节流形式存入字节数组，但是由于3DES是要调用之前写好的DES完成加解密工作。因此，在调用DES处理之前要将数据类型进行转换。而直接将一个字节型数据转换成八个字符型数据是不容易的。所以，将字节型数据进行划分，将它看成是两个16进制数的组合。例如字节型数据“11110001”，可以看成是16进制的“F1”。将字节型数组数据，首先转换成StringBuffer型数据。如图所示。然后再使用Java提供的toString()和toCharArray()方法完成到字符数组的变换。

3.3设计UI界面

使用Java的Jframe进行UI界面的设计。在java中顶层容器有三种，分别是Jframe（框架窗口，即通常的窗口）、JDialog（对话框）、JApplet（用于设计嵌入在网页中的java小程序），顶层容器是容纳其它组件的基础，即设计图形化程序必须要有顶层容器。Java中间容器是可以包含其它相应组件的容器，但是中间容器和组件一样，不能单独存在，必须依附于顶层容器。
常见的中间容器有： JPanel：最灵活、最常用的中间容器。UI界面的展示在报告第四部分给出，代码部分由于不是课程设计的重点不在这里赘述。

4.实验结论和问题解答 4.1实验结论

对项目使用进行说明。用户运行项目可以进入主界面看到如图15所示的选择欢迎界面。如果用户点击加密按钮则跳转到加密界面。在进入加密界面时，用户会看到系统给出的输入格式提示框，指示用户进行格式正确的输入。提示框如图16所示。加密界面如图17所示。在加密界面用户会看到“请选择要加密源文件”，“进行加密”和“返回上一级”三个按钮。用户点击“请选择要加密源文件”按钮，进行源文件的选择，d出如图18所示文件选择框。进行文件选择后，按照提示框要求输入密钥和初始化向量IV后，点击“进行加密”按钮。这时系统会自动完成加密工作，并在所选文件的文件夹中，生成一个与源文件同名但后缀名为“.zqw”的加密后文件，并将文件路径在“结果路径”文本框中给出，同时d出加密成功提示框，如图19所示。
此图略去
图15 主界面

此图略去
图19 加密界面进行加密后

加密成功后，如用户点击“返回上一级”按钮，则可返回主界面。用户可以点击“解密”按钮进入解密界面，用户同样会看到系统给出的输入格式提示框，指示用户进行格式正确的输入（比加密时增加了一个解密后文件后缀名的输入），如图20所示。在解密界面，如图21所示，用户会看到“请选择要解密源文件”，“进行解密”和“返回上一级”三个按钮。用户点击“请选择要加密源文件”按钮，进行源文件的选择，d出如图22所示文件选择框。进行文件选择后，按照提示框要求输入密钥和初始化向量IV，同时要输入解密后文件后缀名，点击“进行解密”按钮。这时系统会自动完成解密工作，并在所选文件的文件夹中，生成一个与源文件同名但后缀名为用户输入的解密后文件，并将文件路径在“结果路径”文本框中给出，同时d出解密成功提示框，如图23所示。

此图略去
图23 解密界面进行解密后
3DES可以很好的保证数据的安全性，本项目实现3DES加解密的基本功能，可以对任意格式的文件进行加解密。为验证算法正确性，在系统完成以后分别对txt文件，jpg文件，exe文件，doc文件，pdf文件进行的加解密 *** 作，最后均能得到正确的结果，相当于对软件进行了黑箱测试，一定程度上可以说明软件的正确性。

4.2问题解答

在实现DES算法时，首先按照书本上的步骤一步一步实现出来，但是最后完成以后，却发现对照老师给出的测试用例不能完全通过。然后就自行检查代码与课本上步骤的出入，以及P盒和S盒的内容。但是经过数遍检查依旧徒劳无功，最后在迫不得已的情况下。我选择大胆猜测是课本上给出的P盒和S盒的内容出错。之后，便去网络上查询S盒的内容，果然在S1盒和S4盒中发现了错误，最后改正过来，才通过了测试用例。
经过如此坎坷的途径之后，我原以为DES算法已经完美实现。后来我才发现我太天真了，在实现DES解密时，根据DES算法加密解密使用同一种算法的准则，只是在加密算法上增加了一个标志，原以为已经实现了。但是，在对密文进行解密时，发现有一些测试用例并不能通过。我百思不得其解，因为加密解密使用同一种算法，加密算法正确，解密算法怎么会错误呢？于是我一行、一行检查代码，经过几个晚上的奋战最后发现原来是在用查表法进行进制转换时对于“A，B，C，D，E，F”这几个十六进制数，忘记减去“A”了。更正之后，顺利通过测试。
在完成DES以后，进一步完成3DES算法。主要是调用写好的DES以及实现字节流的读入写出，CBC工作模式和全零填充。字节流的读入写出，使用Java语言相对而言可能好实现一些。在实现CBC工作模式时，首先对只有两组的数据进行测试，但是第一组可以通过测试，第二组就会发生个别位错误。根据这个错误特性，我推测肯定不是算法整体逻辑的问题（因为那可能会引起全局的变化而不是个别位），而是CBC工作模式的问题。又是几个晚上的奋战，在我快要放弃的时候，终于在一个自定义函数中发现了问题。原理是我不小心改变了第一个分组加密后的内容。更正之后，很快通过测试。最后，设计UI界面，虽然不是太美观但是用户还是便于 *** 作的。UI界面的设计花费了我很多的心思，奈何技术水平有限加上图形美化能力的欠缺，故只能呈现出一个朴实好用，且尽量美观的UI用户界面。
在进行加解密 *** 作时，第一版的3DES发现加解密速度很慢，后来通过检查代码，猜测可能是与涉及到的String型数据的加法 *** 作有关。通过查阅资料和回忆Java课程老师上课所讲，用StringBuffer类型替代了String类型大大提高了算法的执行效率。深入探究后发现原来是，在Java中字符串使用String类进行表示，但是String类表示字符串有一个最大的问题：“字符串常量一旦声明则不可改变，而字符串对象可以改变，但是改变的是其内存地址的指向。”所以String类不适合于频繁修改的字符串 *** 作上，所以在这种情况下，往往可以使用StringBuffer类，即StringBuffer类方便用户进行内容修改。

5.实验体会

通过对3DES加解密算法的实现，我最大的体会就是编写代码要认真，细心。3DES的整体算法在老师讲解，自己学习过以后，并不难理解，但是在具体编程实现时，却有可能遇到这样或者那样的“坑”。而且，很多时候可能是一些细节性的“小问题”。然后，往往正是这些“小问题”，导致了最后算法运行出现了不可预期的错误，浪费大量的时间。
总结来说，通过这次3DES加解密算法的实现，让我对计算机一些底层知识有了更加深刻的认识，直接处理字节流也是学习计算机以来，第一次进行的。在直接处理字节流时，发现例如计算机组成原理， *** 作系统这样的课程还是非常有用的。对3DES加解密算法的实现步骤原理有了更加透彻的理解。同时，对编程要细心这句话有了更加更加深刻的认识。在整个算法的实现过程中，更正由细节问题产生的bug所花费的时间，几乎占到了总时间的一半。这些都是血的教训。在以后的编码过程中，我一定要细心，认真。慢可能是另一种快！这次3DES系统设计，让我将以前所学和信息安全的知识融合起来使得，收获颇丰！