aes加密

在网络请求中许多项目用到了AES加密解密，最近遇到了就顺便写下来，方便记忆。 1、首先下载AESCrypt第三方库，下载下来后编译会报错，需把NSData + CommonCypto.m这个文件添加-fon-objc-arc 2.导入头文件#import "AESCrypt.h" NSString *str = @"uiuberug823u8gno3"; (随意写一个密码) //加密可对字符串，字典等类型进行加密 NSString *string = @"hello"; //对string进行加密 NSString *encstring = [AESCrypt encrypt:string password:str]; //解密 NSString *decstring = [AESCrypt decrypt:encstring password:str]; 来源： https://www.cnblogs.com/ganjinjin/p/5075588.html

--------------------------------------------------------------------------------------------------------------- 为什么会了解加密的这些东西呢？说来很囧的………… 异想天开的想开发一个微信自动加好友软件，卖给微商们，自己也赚点小钱。。。然后就开始搞吧，最先想到的当然是抓取报文咯。结果发现抓来的是乱码！ 无知的我还想通过utraldit编辑器等一些功能来转为正常可读的呢！后来几经查阅资料，得知这是加密后的数据，不解密是无法获取有效信息的。 现在就简单说一下微信中的加密及协议的相关东东吧！ 通信协议： 微信的通信协议比较简单，登陆的时候可能由于有密码或者登陆本身的重要性，采用了SSL加密传输，其余的聊天、朋友圈、搜好友等等都是采用的HTTP协议； 加密方式： 如今微信的用户群已经做到如此庞大，并且涉及到安全支付等重要信息，加密工作自然得做的非常好；据查阅资料得知大概是这样的：客户端要发送的消息， 首先采用AES加密 ，在此基础上 再采用RAS加密 ；这样的话，只有先破解RAS加密，再破解AES加密，才能获取有效信息；由于本人之前对加密等知识一无所知，所以就学习这些加密的东西咯； -------------不过话说回来，据我推测，自动加好友软件应该不需要完全破解微信的加密协议

分组密码有五种工作体制：1. 电码本模式（Electronic Codebook Book (ECB)）；2.密码分组链接模式（Cipher Block Chaining (CBC)）；3.计算器模式（Counter (CTR)）；4.密码反馈模式（Cipher FeedBack (CFB)）；5.输出反馈模式（Output FeedBack (OFB)）。 以下逐一介绍一下： 1.电码本模式（ Electronic Codebook Book (ECB) 这种模式是将整个明文分成若干段相同的小段，然后对每一小段进行加密。 2.密码分组链接模式（Cipher Block Chaining (CBC)） 这种模式是先将明文切分成若干小段，然后每一小段与初始块或者上一段的密文段进行异或运算后，再与密钥进行加密。 3.计算器模式（Counter (CTR)） 计算器模式不常见，在CTR模式中， 有一个自增的算子，这个算子用密钥加密之后的输出和明文异或的结果得到密文，相当于一次一密。这种加密方式简单快速，安全可靠，而且可以并行加密，但是 在计算器不能维持很长的情况下，密钥只能使用一次 。CTR的示意图如下所示： 4.密码反馈模式（Cipher FeedBack (CFB)） 这种模式较复杂。 5.输出反馈模式（Output FeedBack (OFB)） 这种模式较复杂。 以下附上C+

下面我们来一起学习一下 HTTPS ，首先问你一个问题，为什么有了 HTTP 之后，还需要有 HTTPS ？我突然有个想法，为什么我们面试的时候需要回答 标准答案 呢？为什么我们不说出我们自己的想法和见解，却要记住一些所谓的标准回答呢？ 技术还有正确与否吗 ？ HTTPS 为什么会出现 一个新技术的出现必定是为了解决某种问题的，那么 HTTPS 解决了 HTTP 的什么问题呢？ HTTPS 解决了什么问题 一个简单的回答可能会是 HTTP 它不安全。由于 HTTP 天生明文传输的特性，在 HTTP 的传输过程中，任何人都有可能从中截获、修改或者伪造请求发送，所以可以认为 HTTP 是不安全的；在 HTTP 的传输过程中不会验证通信方的身份，因此 HTTP 信息交换的双方可能会遭到伪装，也就是 没有用户验证 ；在 HTTP 的传输过程中，接收方和发送方并 不会验证报文的完整性 ，综上，为了结局上述问题，HTTPS 应用而生。 什么是 HTTPS 你还记得 HTTP 是怎么定义的吗？HTTP 是一种 超文本传输协议(Hypertext Transfer Protocol) 协议， 它 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范 ，那么我们看一下 HTTPS 是如何定义的 HTTPS 的全称是 Hypertext Transfer

最近在做一个node项目，需要对前端传递给node端的敏感数据进行加密，并在node端对该加密数据进行解密；因为在做node项目之前，与后端配合开发过类似的需求，即前端加密后端解密；所以就尝试采用RSA非对称加密算法来实现。由于第一次采用RSA来完成加解密的整个过程，遇到了不少坑；不过由于种种原因，最后采用了AES的加密方式；下面就来说说前端加解密实现方案。 RSA加解密算法 实现思路 当然首先想到采用的加解密算法就是 RSA ，其关键在于算法的 公钥/秘钥 。其主要用法： 算法生成一份公钥和私钥，其中公钥是公开的，所有人都可以知道，私钥是保密的 用公钥解密，要用私钥解密 于是，基于RSA算法来实现加解密，找到了对应的浏览器端库 jsencrypt 和node端的库 node-rsa 来实现具体的功能。 具体实现思路： 使用 jsencrypt 在前端实现用公玥加密，使用 node-rsa 在node端用私钥解密。 遇到的坑 由于采用的是RSA算法，所以需要前后端约定具体的公钥和私钥。怎么生存公钥私钥呢？ 于是根据 jsencrypt 库的介绍，使用 openssl 方式来生成对应的公钥和私钥。于是生成的公钥和私钥大概是如下样子： // 私钥 -----BEGIN RSA PRIVATE KEY-----

transformation：“算法/模式/填充”或“算法” public static final Cipher getInstance ( String transformation ) { return createCipher ( transformation , null ) ; } 使用第三方库进行aes解密，传入加密的16进制的数据、密钥、算法/模式/填充、偏移量；得到解密后的数据 byte [ ] bytes = EncryptUtils . decryptHexStringAES ( encryptData , key . getBytes ( ) , "AES/CBC/PKCS5Padding" , iv . getBytes ( ) ) ; String data = new String ( bytes ) ; 来源： CSDN 作者： 倒骑驴走着瞧 链接： https://blog.csdn.net/nongminkouhao/article/details/104802708

分组密码在加密时明文分组的长度是固定的，而实用中待加密消息的数据量是不定的，数据格式可能是多种多样的。为了 能在各种应用场合安全地使用分组密码 ，通常对不同的使用目的运用不同的工作模式。 一、电码本模式（ECB） 将整个明文分成若干段相同的小段，然后对每一小段进行加密。 优：操作简单，易于实现；分组独立，易于并行；误差不会被传送。——简单，可并行，不传送误差。 缺：掩盖不了明文结构信息，难以抵抗统计分析攻击。——可对明文进行主动攻击。 二、密码分组链模式（CBC） 先将明文切分成若干小段，然后每一小段与初始块或者上一段的密文段进行异或运算后，再与密钥进行加密。 优点 ：能掩盖明文结构信息，保证相同密文可得不同明文，所以不容易主动攻击，安全性好于ECB，适合传输长度长的报文，是SSL和IPSec的标准。 缺点 ：（1）不利于并行计算；（2）传递误差——前一个出错则后续全错；（3）第一个明文块需要与一个初始化向量IV进行抑或，初始化向量IV的选取比较复杂。 初始化IV的选取方式 ：固定IV，计数器IV，随机IV（只能得到伪随机数，用的最多），瞬时IV（难以得到瞬时值） 三、输出反馈模式（OFB） 密码算法的输出（指密码key而不是密文）会反馈到密码算法的输入中，OFB模式并不是通过密码算法对明文直接加密，而是通过将明文分组和密码算法的输出进行XOR来产生密文分组。 优点

花了很长时间，感叹啊 刚开始是打算在网上能找个现成的代码，直接合到Qt工程里就结束了的，但是找来找去，加密后的文件都和想要的对不上，最后放弃了直接找现成的，潜心去看了看详细的算法介绍，深入了解了一下什么是AES256 CBC加密 AES加密算法的详细介绍与实现 ， 感谢这位版主，文章写的很详细，看了详细介绍后自己手动修改了手头代码后最终实现啦 来源： CSDN 作者： weixin_39291453 链接： https://blog.csdn.net/weixin_39291453/article/details/104551978

AES CFB/OFB/ECB/CBC/CTR优缺点 摘自：http://www.metsky.com/archives/418.html 发表时间：2010年05月11 分类: 网络日志 作者: 天缘 AES常见加密模式有CFB/OFB/ECB/CBC/CTR，本文概述这些算法特点，让大家更快的了解AES，当然天缘也不是专业做算法的，工作中也只是使用到才会学习一点，如有错误，欢迎指出。 一、Cipher feedback（CFB） CFB算法优点： 同明文不同密文，分组密钥转换为流密码。 CFB算法缺点： 串行运算不利并行，传输错误可能导致后续传输块错误。 二、Output feedback（OFB） OFB算法优点： 同明文不同密文，分组密钥转换为流密码。 OFB算法缺点： 串行运算不利并行，传输错误可能导致后续传输块错误。 三、Electronic codebook(ECB) ECB算法优点： 简单、孤立，每个块单独运算。适合并行运算。传输错误一般只影响当前块。 ECB算法缺点： 同明文输出同密文，可能导致明文攻击。我们平时用的AES加密很多都是ECB模式的，此模式加密不需要向量IV。 四、Cipher-block chaining（CBC） CBC算法优点： 串行化运算，相同明文不同密文 CBC算法缺点： 需要初始向量，不过这其实不算缺点，下文的CTR也是需要随机数的

简介 加密是指通过使用密钥或密码对数据进行模糊处理的过程。在SQL Server中，加密并不能替代其他的安全设置，比如防止未被授权的人访问数据库或是数据库实例所在的Windows系统，甚至是数据库所在的机房，而是作为当数据库被破解或是备份被窃取后的最后一道防线。通过加密，使得未被授权的人在没有密钥或密码的情况下所窃取的数据变得毫无意义。这种做法不仅仅是为了你的数据安全，有时甚至是法律所要求的（像国内某知名IT网站泄漏密码这种事在中国可以道歉后不负任何责任了事，在米国妥妥的要破产清算）。 SQL Server中的加密简介 在SQL Server2000和以前的版本，是不支持加密的。所有的加密操作都需要在程序中完成。这导致一个问题，数据库中加密的数据仅仅是对某一特定程序有意义，而另外的程序如果没有对应的解密算法，则数据变得毫无意义。 到了SQL Server2005，引入了列级加密。使得加密可以对特定列执行，这个过程涉及4对加密和解密的内置函数 SQL Server 2008时代，则引入的了透明数据加密（TDE），所谓的透明数据加密，就是加密在数据库中进行，但从程序的角度来看就好像没有加密一样，和列级加密不同的是，TDE加密的级别是整个数据库。使用TDE加密的数据库文件或备份在另一个没有证书的实例上是不能附加或恢复的。 加密的一些基础知识