文章不易，请关注公众号 毛毛虫的小小蜡笔，多多反对，谢谢。 有任何问题都能够留言征询。 问题两个平台我的项目中，各自的前后端的明码传输，都用了非对称RSA加密。 流程是这样的：平台A的前端，须要把加密后的密文传给平台B的前端，而后平台B的前端都会对明码进行加密，而后再传输给平台B的后端。平台B的后端解密后，再传输给平台A的后端。 导致的问题：因为平台B的前端，拿到的明码是曾经在平台A加密过的密文，此时再次加密，就会报错。 如下截图所示： 前端用的是jsencrypt库，报错的意思是文本太长了。 详情 请查看：毛毛虫的小小蜡笔
需要首先在golang中生成keypair，javascript向golang发送数据前，先申请publickey API获取publickey，而后基于publickey加密数据，最初将被加密的数据发送给golang。 实现一、golang生成keypairvar ( privateKey *rsa.PrivateKey publicKey *rsa.PublicKey publicKeyString string)if pri, err := rsa.GenerateKey(rand.Reader, 32); err != nil { panic(err)} else { privateKey = pri publicKey = &pri.PublicKey}// 将publicKey转换为PKIX, ASN.1 DER格局if derPkix, err := x509.MarshalPKIXPublicKey(publicKey); err != nil { return err} else { // 设置PEM编码构造 block := pem.Block{ Type: "RSA PUBLIC KEY", Bytes: derPkix, } // 将publicKey以字符串模式返回给javascript publicKeyString = string(pem.EncodeToMemory(&block))}二、javascript应用publickey加密数据装置jsencrypt npm install jsencrypt获取publickey const [pk, setPK] = useState('')useEffect(() => { fetch(`${url}`, {method: 'GET'}) .then(r => r.json()) .then(d => { if (d.hasOwnProperty('public_key')) setPK(d.public_key) else alert('API返回值短少必要字段！') }) .catch(e => {alert(e)})}, [])加密用户数据 ...
已有服务器应用的是ASP.net进行RSA加密，新服务器应用koa2，加密后的后果应用nodejs自带的crypto和node-rsa均无奈解密，起因未明。试用多个组件后，发现node-jsencrypt的加密解密后果能够通用。故特意记录。 简略的解密流程： const JSEncrypt = require("node-jsencrypt");const PUBLICKEY = `-----BEGIN PUBLIC KEY-----MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCFSws2t8RQ8IlrXQmkE7lOYQ5hXya+HdXrBDh5zGv3+suPEj8K+sLuPfsGCRC6VbyKkzwGECNrzwOPWTx7szHMp4OuIRCe8wEyV2TAri7eRukgelXVG4Fh4F1jS14jdWeTfRXFxygkkGTyCvKbWzm9Hp93fNKDHuB+bTvRS9YMuwIDAQAB-----END PUBLIC KEY-----`;//公钥 const rsaEncrypt = `密文`; let jsencrypt = new JSEncrypt(); jsencrypt.setPrivateKey(PRIVATEKEY); let decrypt = jsencrypt.decrypt(rsaEncrypt)字符串长度超过117时，该组件就不能间接解密，如果超长字符串加密，须要进行宰割解决长字符串的加密解决： //宰割 if (querystr.length > 117) { let cnt = Number.parseInt(querystr.length / 117) + 1; ori_slice.push(querystr.slice(0, len_max)) for (let i = 1; i < cnt; i++) { const _slice = querystr.slice(len_max * i).trim(); if (_slice.length > 0) { ori_slice.push(querystr.slice(len_max * i)); } } }//加密并组合let encrypt_list = ori_slice.map(i => { let jsencrypt = new JSEncrypt(); jsencrypt.setPublicKey(PUBLICKEY); let encrypt = jsencrypt.encrypt(i); return encrypt; }); let encrypt_query = encrypt_list.join('::');//以::双冒号划分解密时，分段解密并拼接即可 ...
前言编程中常见的加密算法有以下几种，它们在不同场景中别离有利用。除信息摘要算法外，其它加密形式都会须要密钥。 信息摘要算法对称加密算法非对称加密算法密钥密钥（key，又常称金钥）是指某个用来实现加密、解密、完整性验证等密码学利用的机密信息。 密钥分类加解密中的密钥：对称加密中共享雷同的密钥，非对称加密中分公钥和私钥，公钥加密私钥解密。音讯认证码和数字签名中的密钥：在音讯认证码中，音讯发送方和接管方应用共享密钥进行认证。在数字签名中，签名应用私钥，而验证应用公钥。会话密钥和主密钥：每次通信只应用一次的密钥称为会话密钥（session key）。绝对于会话密钥，重复使用的密钥称为主密钥（master key）。密钥和明码明码个别是由用户生成，具备可读性，能够记忆和存储，罕用于软件治理，而密钥是供实现加密算法的软件应用，不须要具备可读性（不过在编程中为了不便浏览都进行Base64）。咱们也能够通过明码来生成密钥。 密钥治理生成密钥：能够用随机数生成密钥，也能够用口令生成密钥。配送密钥：可采纳当时共享密钥、应用密钥调配核心、应用公钥明码、应用Diffie-Hellman密钥替换。更新密钥保留密钥作废密钥密钥生成jdk 中 jce (Java Cryptography Extension) 蕴含了加密相干的所有API。 生成对称加密算法的密钥 public static SecretKey generateKey(int keySize) { KeyGenerator keyGenerator; try { keyGenerator = KeyGenerator.getInstance("AES"); keyGenerator.init(keySize); return keyGenerator.generateKey(); } catch (NoSuchAlgorithmException e) { // ignore return null; } }生成对称非对称加密算法的密钥 /** * 生成非对称密钥对 * * @param keySize 密钥大小 * @param random 指定随机起源，默认应用 JCAUtil.getSecureRandom() * @return 非对称密钥对 * @throws NoSuchAlgorithmException NoSuchAlgorithm */ public static PPKeys genKeysRSA(int keySize, SecureRandom random) throws NoSuchAlgorithmException { KeyPairGenerator generator = KeyPairGenerator.getInstance("RSA"); if (null != random) { generator.initialize(keySize, random); } else { generator.initialize(keySize); } KeyPair pair = generator.generateKeyPair(); PPKeys keys = new PPKeys(); PublicKey publicKey = pair.getPublic(); PrivateKey privateKey = pair.getPrivate(); keys.setPublicKey(Base64.getEncoder().encodeToString(publicKey.getEncoded())); keys.setPrivateKey(Base64.getEncoder().encodeToString(privateKey.getEncoded())); return keys; }密钥协商（Diffie-Hellman） ...
在理论利用的时候，非对称加密总是和对称加密一起应用。假如小明须要给小红须要传输加密文件，他俩首先替换了各自的公钥，而后： 1.小明生成一个随机的AES口令，而后用小红的公钥通过RSA加密这个口令，并发给小红；2.小红用本人的RSA私钥解密失去AES口令；3.单方应用这个共享的AES口令用AES加密通信。可见非对称加密实际上利用在第一步，即加密“AES口令”。这也是咱们在浏览器中罕用的HTTPS协定的做法，即浏览器和服务器先通过RSA替换AES口令，接下来单方通信实际上采纳的是速度较快的AES对称加密，而不是迟缓的RSA非对称加密。
RSA原理和数学根底不再赘述，网上材料比拟多，本文重点剖析，RSA信息如何在证书等相干畛域的利用。 RSA密钥生成过程大略是这样的， p、q: 随机找两个大素数p、q，n:把它们的乘积后果记为n(n):计算n的欧拉函数(n) = (p-1)(q-1)e:随机抉择一个整数e，条件是1< e < (n)，且e与(n) 互质。（理论利用中，经常抉择65537。）d:d满足 ed ≡ 1 (mod (n))将n和e封装成公钥，n和d封装成私钥。证书信息以思否网站的证书为例，咱们看到应用的非对称加密是RSA 公钥信息RSA(2048Bits)阐明，公钥长度是2048个比特，也就是n这个十进制大整数转换为二进制的bit个数。依据RSA密钥生成过程，公钥是又n和e组成，e个别用65537。那么，在证书的公钥信息里，n和e在哪里？然而数上面的30 82 01 0a...的所有字节，增强远超过2048bit。 到这，不得不提ASN.1编码，人们为了不便存储、传输、替换信息而制订的编码方式，这种编码方式是独立于任何零碎和设施的，以达到跨零碎，跨畛域传输通用性。咱们晓得，RSA生成公钥，就是n和e，n和e，通过ASN.1的编码标准进行编码，这样，任何人，任何设施，只有依照标准去解码，必定可能获取n和e，其实就是ASN.1编码对立通信语言。好了，到这里，咱们晓得，证书的公钥信息是ASN.1编码的，那就依照编码标准，解析出n和e即可，其实很简略，n和e就嵌在公钥信息里，间接提取就行。 30 82 01 22 30 0d 06 09 2a 86 48 86 f7 0d 01 0101 05 00 03 82 01 0f 00 30 82 01 0a 02 82 01 0100 ba 3c 0b 9f a4 6a 8c 70 37 c2 eb 69 b7 07 f6c0 b9 3d 83 28 8b a2 db e9 96 88 23 fc ca 43 1c2b 68 1c 63 12 67 94 0e 20 61 8f b0 28 96 7a e542 e6 61 e2 35 32 5b b4 0d 7d 6b 65 5b c4 7d 3e91 4a c8 af 81 fb c7 aa 02 dd 69 e7 5b 31 68 79ff 41 65 5e 32 e3 f1 6a 81 20 c9 c2 ff 4b e1 ab14 a2 ce b0 39 15 86 35 7a d9 25 b1 5a 32 a4 cc3a fe 35 7c 05 5e 41 9a 9a 88 6f f9 5f 28 18 7b6c 3d fc b1 04 7a 29 4f 34 00 01 b0 97 f9 4e bce8 ad e7 5d 98 8e ed 3b 3b d0 01 87 8b 63 4e c38d e5 1f bf 80 39 e5 80 c8 06 4f 35 40 c9 de 3b42 50 2c 73 fe 51 8a 8a ea dd 38 77 8b 6f 34 9941 bb f1 3f 9e 09 29 53 ff ec f6 92 04 bf 77 f7b6 48 11 05 39 22 86 1b 72 fe 4d 94 a3 7d 48 c81c f9 eb 93 87 06 e0 d5 69 61 e2 9e 2c 38 d8 8d63 38 ab 32 7d 7c a5 50 bf 8b 83 0c 5e 7e 76 ca65 02 03 01 00 01 ...
大家好，我是永强，就是老李之前经常给你们说的区块链大神、大学肄业却依然大公司iOS主程一波儿流、只生活在老李口中尚未真实露面的骗钱高手、老王的左膀右臂 ——— 赵永强。我和尼古拉斯赵四之间并没有什么强关联，我只是单方面认识他而已。 之前老李企图让我发表一些关于如何进行高端骗工资骗钱的教程，被我义正言辞地拒绝了： 毕竟是毕生绝学，不能就这么轻而易举地教给你们不过后面有时间我可以给大家出一些关于“如何在公司混日子还能升职加薪”的入门级教程，传男不传女，独家绝技！敬请期待！ 言归正传，那个一直以来我对加解密技术都是耿耿于怀的，因为很多年前有一次面试中被这东西给坑掉了，虽然我后来就自己对加解密中一些自己不懂的地方请教了对方而且他也没有给我讲清楚… 事情都过去好几年了，本人自我感觉已经一定程度掌握了一些关于加密的高端技术，因为决定出来装一波儿逼，时间比较紧张，我打算赶在2020年农历新年之前把逼装完，你们要注意配合。 我知道老李之前在社区发表了一些关于加密啊、解密啊之类的东西，甚至还扯上了什么DH什么ECDH，又是质数又是椭圆曲线，不过这并不与本系列产生冲突，这并不重要，不要在意这些细节，他那个too young too simple，sometimes naive… 这将是一个大概由四篇左右的文章组成的系列文章，所以在正式开始之前，我不得不强调一点 ——— 如下这几门学科的基础理论知识： 《离散数学》《微分与积分》《空间几何》《概率论》你并不需要具备。。。 不过你总得知道除了html和css之外的任意一门编程语言。尽管本人精通上到CLanguage下到Perl之类的各种语言，但是本文将采用世界上最好的语言进行一些程序演示，后面老李可能会使用CLanguage和Golang进行其他语言的演示补充。 简单说来呢，加解密技术就是分为两大类： 对称加解密非对称加解密其中，常见的对称加解密算法有DES、3DES、AES；而非对称加解密技术比较典型的则是RSA，就是什么公钥私钥证书什么乱七八糟的。 我们先从对称加解密开始，粗暴地说呢，对称加解密就是“加密和解密的时候用同一个密码”，听起来就非常对称，有没有？ 用图表达一下就是： 最一开始的时候，我朝人民一般都是倾向于使用“天王盖地虎”，“宝塔镇河妖”这种加解密技术；然而，美帝用了一种叫做DES的技术进行对称加解密，这玩意一度成为业界通用的对称加解密技术，银行、五角大楼都爱用这玩意，可惜好景不长、世风日下、世态炎凉，这玩意的破解成本越来越低越来越低～～ 于是，为了续命，就又有一些白胡子老头给DES打补丁，缝缝补补搞出来一个玩意叫做3DES，继续用，又不是不能用…这个顾名思义就行了，别打我，真的：3DES就是用DES处理（注意是处理，我没说是加密）了三次的意思。就目前看来，3DES实际上用的可能也并不是十分广泛了，所以如果大家在选择对称加解密技术的时候，尽量避开DES和3DES就可以了。 呵呵，喜新厌旧的沙雕人类…虽然DES已经没人用了，但毕竟也是辉煌过，我觉得还是得动手表演一波儿。我们知道，在php7里，原来的mcrypt系列加解密已经被放弃掉了，官方建议我们使用openssl系列来进行加解密，所以确保你的PHP环境里安装了openssl标准扩展。 <?php// 这个函数打印出来openssl支持的所有加密方法以及模式的组合$arr_ava_methods = openssl_get_cipher_methods();print_r( $arr_ava_methods );文件保存成test.php后，执行一把：php test.php | grep des，结果你们感受一下： 其中带有ede的，比如des-ede*这样的就表示是3DES。还有这么多奇奇怪怪的后缀是什么含义？回头再说…又不是不能用。 筛选一下，我们看des（非des3）有几种带着尾巴的具体方法： des-cbcdes-cfb*（注意后面的通配符星号）des-ecbdes-ofb我们先用传统des方法继续进行装逼表演： <?php// 我们就选用des-ecb方法进行一次des加密$ava_methods = openssl_get_cipher_methods();$my_method = 'des-ecb';if ( !in_array( $my_method, $ava_methods ) ) { exit( '错误的加密方法'.PHP_EOL );}$key = "123456";$data = "helloMOTO";echo "明文：".$data.PHP_EOL;$enc_data = openssl_encrypt( $data, $my_method, $key );echo "密文：".$enc_data.PHP_EOL;$dec_data = openssl_decrypt( $enc_data, $my_method, $key );echo "明文：".$dec_data.PHP_EOL;保存为test.php执行一把： ...
前言因公司现有后台管理系统项目需对部分网络请求接口的重要数据进行加密，整合了一套简单的基于 RSA + AES 加密机制的前端解决方案。 参考文献：crypto 廖雪峰crypto-js aes 加解密rsa 加解密参考 API：crypto-jsJSEncrypt依赖crypto-js： npm i crypto-jsJSEncrypt：npm i jsencrypt加密流程先上图 因项目为后台管理系统，所以这里会有两种业务场景：用户在未登录前是没有鉴权 token 的，需在成功登录并获取 token 后和 encryptKey 一并上传后端，后端才能将 token 与 encryptKey 做绑定。用户已登录成功，页面刷新后将会重新生成 aesKey ，这时候需从 cookie 中获取 token 并和 encryptKey 上传后端，后端重新绑定 token 和 encryptKey。代码encryption.js 封装import CryptoJS from 'crypto-js'import JSEncrypt from 'jsencrypt'const encryptor = new JSEncrypt()// 生成 AESKEYexport const aesKey = createAesKey()export function createAesKey () { const expect = 16 let str = Math.random().toString(36).substr(2) while (str.length < expect) { str += Math.random().toString(36).substr(2) } str = str.substr(0, 16) return str}/** * AES 加密 * @param word 待加密字段 * @param keyStr 加密 key * @returns {string} 返回加密字段 */export function aesEncrypt (word, keyStr) { keyStr = keyStr || aesKey console.log(keyStr) const key = CryptoJS.enc.Utf8.parse(keyStr) let srcs = '' switch (typeof (word)) { case 'string': srcs = CryptoJS.enc.Utf8.parse(word) break case 'object': srcs = CryptoJS.enc.Utf8.parse(JSON.stringify(word)) break default: srcs = CryptoJS.enc.Utf8.parse(word.toString()) } const encrypted = CryptoJS.AES.encrypt(srcs, key, {iv: key, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7}) return encrypted.toString()}/** * AES 解密 * @param word 待解密数据 * @param keyStr 解密 key * @returns {string} 返回解密字符串 */export function aesDecrypt (word, keyStr) { keyStr = keyStr || aesKey const key = CryptoJS.enc.Utf8.parse(keyStr) const decrypt = CryptoJS.AES.decrypt(word, key, { iv: key, mode: CryptoJS.mode.CBC, padding: CryptoJS.pad.Pkcs7 }) return CryptoJS.enc.Utf8.stringify(decrypt).toString()}/** * RSA 设置公钥 * @param val 公钥 */export function setPublicKey (val) { encryptor.setPublicKey(val)}/** * RSA 加密 * @param data 待加密数据 * @returns {PromiseLike<ArrayBuffer>} 返回加密字符串 */export function rsaEncrypt (data) { return encryptor.encrypt(data)}总结AES 加解密涉及到的模式（如 CBC、ECB 等）、偏移量和填充等，请参考文中前言提及的文献和 API本文仅为解决方案参考，请结合实际业务需求及业务场景自由发挥 ...
1、RSA和AES的区别： 总结于：http://www.360doc.com/content... RSA： 是公开密钥系统的代表； 安全性：建立在具有大素数因子的合数，其因子分解困难这一法则之上； 处理速度慢； 密钥管理：加解密过程中不必网络传输保密的密钥；密钥管理优于AES算法； RSA加解密速度慢，不适合大量数据文件加密； AES： Rijndael算法是新一代的高级加密标准，运行时不需计算机有非常高的处理能力和大的内存； 操作可以很容易的抵御时间和空间的攻击，在不同的运行环境下始终保持良好的性能； AES密钥长度：最长只有256bit，可用软件和硬件实现高速处理； 密钥管理：要求在通信前对密钥进行秘密分配，解密的私钥必须通过网络传送至加密数据接收方； AES加密速度很快； AES+RSA： 使用AES对称密码体制对传输数据加密，同时使用RSA不对称密码体制来传送AES的密钥，就可以综合发挥AES和RSA的优点同时 避免它们缺点来实现一种新的数据加密方案 2、RSA签名和验签的流程图： 特点：只需交换公钥；公/秘钥机制，公钥加密，私钥解密；（或者私钥加密，公钥解密）；公钥负责加密，私钥负责解密；私钥负责签名，公钥负责验证。 缺点：加解密速度慢，特别是解密 3、AES框图： 特点：加解密用同一秘钥 优点：速度快，效率高； 存在的问题：秘钥交换问题 摘自：http://www.360doc.com/content... 4、AES+RSA=数据加密方案： 摘自：http://www.360doc.com/content... 流程： 接收方创建RSA秘钥对， 发送RSA公钥给发送方，自己保留RSA私钥 发送方创建AES密钥，加密待传送的明文，之后用RSA公钥加密该密钥， RSA公钥加密AES的密钥+AES密钥加密明文的密文----通过Internet发给---->接收方 接收方用RSA私钥解密加密的密钥，之后再用解密后的AES密钥解密数据密文，得到明文。作者：0914_h 来源：CSDN 原文：https://blog.csdn.net/huanhua... 版权声明：本文为博主原创文章，转载请附上博文链接！
概览工作中，我们时刻都会和接口打交道，有的是调取他人的接口，有的是为他人提供接口，在这过程中肯定都离不开签名验证。 在设计签名验证的时候，一定要满足以下几点： 可变性：每次的签名必须是不一样的。时效性：每次请求的时效性，过期作废。唯一性：每次的签名是唯一的。完整性：能够对传入数据进行验证，防止篡改。下面主要分享一些工作中常用的加解密的方法。 常用验证举例：/api/login?username=xxx&password=xxx&sign=xxx 发送方和接收方约定一个加密的盐值，进行生成签名。 示例代码： //创建签名private function _createSign(){ $strSalt = '1scv6zfzSR1wLaWN'; $strVal = ''; if ($this->params) { $params = $this->params; ksort($params); $strVal = http_build_query($params, '', '&', PHP_QUERY_RFC3986); } return md5(md5($strSalt).md5($strVal));}//验证签名if ($_GET['sign'] != $this->_createSign()) { echo 'Invalid Sign.';}上面使用到了 MD5 方法，MD5 属于单向散列加密。 单向散列加密定义把任意长的输入串变化成固定长的输出串，并且由输出串难以得到输入串，这种方法称为单项散列加密。 常用算法MD5SHAMACCRC优点以 MD5 为例。 方便存储：加密后都是固定大小（32位）的字符串，能够分配固定大小的空间存储。损耗低：加密/加密对于性能的损耗微乎其微。文件加密：只需要32位字符串就能对一个巨大的文件验证其完整性。不可逆：大多数的情况下不可逆，具有良好的安全性。缺点存在暴力破解的可能性，最好通过加盐值的方式提高安全性。应用场景用于敏感数据，比如用户密码，请求参数，文件加密等。推荐密码的存储方式password_hash() 使用足够强度的单向散列算法创建密码的哈希（hash）。 示例代码： //密码加密$password = '123456';$strPwdHash = password_hash($password, PASSWORD_DEFAULT);//密码验证if (password_verify($password, $strPwdHash)) { //Success} else { //Fail}PHP 手册地址： http://php.net/manual/zh/func... 对称加密定义同一个密钥可以同时用作数据的加密和解密，这种方法称为对称加密。 常用算法DESAESAES 是 DES 的升级版，密钥长度更长，选择更多，也更灵活，安全性更高，速度更快。 ...
为什么标题总是要带上“API安全”关键字呢？因为我想我乐意。 实际上这一篇和上一篇均可以看作是《关于PHP加解密的懒汉入门篇(API安全加强篇一)》》")的后续，只不过侧重点在于安全上。 如果说，你没有看上篇，你一定回去看，不然一定会断篇儿！ 为了避免文章陷入过于抽象复杂的理论讲解，所以这次还得借助元首和东线的将领们以及“反派角色”朱可夫同志。 人民好演员列表：男一元首： 男二古德里安： 路人甲曼施坦因： 路人乙冯*博克 “反派”男一 上篇我们知道元首和古德里安翻脸了，然后两个人通过非对称加密技术diss彼此，朱可夫没有私钥只能在路边儿打酱油。 根据事实，我们知道古德里安又重返了东线战场。当初把人撸了下来，现在又得让人去东线救火，反正这脸我是拉不下来，但元首拉的下来。 回到上篇结果提到的问题，就是：对称加密的安全性要人命，非对称加密的性能非常要人命。用我党地话来说就是“不能多快好省”，不符合“可持续发展”，不满足“社会主义主流价值观”。 这篇主要就是说“多快好省”的绿色方案。 让古德里安回东线肯定得是秘密下令的，加密是肯定。但是这个地方一定要值得注意：那就是元首一定得是用古德里安同志的给他公钥进行加密，然后再发送出去，此时这个密文虽然在东线用飞机撒的满地都是，但是只有古德里安同志自己能用藏在自己裤裆里的私钥进行解密后才能得到明文，也就是说这事儿也只有古德里安和元首两个人知道了。 除此之外，还有两种情况，可能爱思考的青年已经考虑到了： 元首是不是可以利用自己的公钥对密文进行加密。但这种做法的最终结果就是这个密文只能用元首的私钥进行解密，但是元首的私钥在元首的裤裆里，别人是无法知道的。元首作为高智商罪犯，这种低级错误是不可能犯的。元首用自己的私钥对密文进行加密。这个时候就意味着只有持有元首公钥的东线将领们才可以解密这个密文，然而假如元首并不想让其他人知道他天才一般的部署，这种方式就显得有点儿2了。综上，这种情况下，最正确的方式就是元首利用古德里安的公钥对密文进行加密，然而再撒的满天飞，这会儿只有古德里安能用自己的私钥进行解密。此时，无论是自己家的曼施坦因、冯*博克，还是“反派”的朱可夫，都只能默默当路人甲。 在上述案例中（注意，客户端不要理解为狭义角度的手机客户端！） 元首充当API服务器的角色。古德里安充当客户端的角色。曼施坦因、冯*博克充当路人甲客户端角色。朱可夫充当中间劫持者的角色。我们回归到现实中，也就是真正搬砖撸代码的现实中。这个时候，如果要对服务器和客户端传输的数据进行非对称加密，那么就得有如下条件： 客户端有自己一对公钥私钥，客户端持有服务器的公钥服务器有自己一对公钥私钥，服务器持有客户端的公钥那么问题来了，服务器只有少数一台，客户端成千上万。这会儿摆在搬砖侠们面前的只有两个选择： 客户端的公钥和私钥共用一对，这样服务器只要一个公钥就算是拥有了所有客户端的公钥客户端的公钥和私钥都是特立独行的，是颜色不一样的烟火。这会儿服务器就苦逼了，必须维护一坨彼此不同的客户端，同时还要建立和不同客户端的对应关系那么，好了，下面让各位搬砖侠们吃口屎保持一下冷静，我们看看支付宝是怎么做的。当你的系统接入支付宝的时候，支付宝会要求你生成一对你的公私钥，然后私钥你自己藏好了，公钥上传到支付宝（这个过程相当于支付宝有了你的公钥），然后再你上传完你的公钥后，支付宝会返回给你支付宝的公钥。其中当你使用RSA普通版本的时候，所有商户得到的支付宝公钥都是同一个，当你使用RSA2的时候，每个商户收到的支付宝公钥都是不尽相同的。 所以说，怎么做都行，一切都看你选择。 说起支付宝，你们接入的时候都一定看到有个叫做签名验证的功能，我认为这个很重要，是必须值得一提的一件事情。回到元首这里来，我们说元首给古德里安发消息“滚到东线，去库尔斯克棱角部”，正确的做法应该是用古德里安的公钥进行加密，此时该消息只能被古德里安的私钥解密，其他人都只能干瞪眼。如果元首抽风了，用自己的私钥加密了密文，这会儿会是什么情况咧？那就是持有元首公钥的人都可以看到“滚到东线，去库尔斯克棱角部”这条机密消息了，很多人都会发朋友圈或者私聊类似于“听说古德里安要回来了”。其实，用自己私钥解密，然后利用自己公钥解密是一个二逼的行为，但是，这个过程可以用来验签是没有任何问题的。什么是验签？ 假如有一天，希姆莱想提前篡位，冒充元首给古德里安发号施令了。此时，古德里安只需要用元首的公钥验证一下命令的签名，一验返回了false，那就说明这坨命令不是来自于元首，这种数据就应该直接扔掉即可！ 所以，上面叨逼叨叨逼叨这么久，为的就是得出一个结论，你们理（bei）解（song）一下： 公钥加密，私钥解密私钥加密，公钥验签然后我们再往前追溯一下，我们的为什么要用非对称加密？是为了防止对称加密措施密钥的泄漏，而非对称加密不存在密钥泄漏的情况。 但是，非对称加解密的性能以及部署使用方式，非土豪所能及也！那么，有没有办法既能得到鱼，又能得到熊掌咧？ 最近开了一个微信公众号:高性能API社区，所有文章都先发这里
懒汉入门这两点就足以说明这篇文章不想要着有什么高端大气的技术内容，我跟你讲，全是水。不可能有什么质数素数、椭圆曲线加密、迪菲-赫尔曼什么的，不可能有的。 首先我不懂，其次，反正你们也不懂。 不过这里还是要先说一点儿，就是很多泥腿子一直拿md5当加密算法来看待，但实际上md5是一种信息摘要算法（其实就是哈希），不是加密算法，因为md5不可逆，但是加解密是一个可逆的过程，所以以后这种低级错误还是不要犯的为好。 加密技术一直是技术圈中的一个独特领域和分支，其一些原理并不是随随便便就可以理解的来的。如果没有良好的数学底子，怕是很难研究下去。但是，作为一篇水文，不研究原理，仅仅来用一用来实践一把，还是没什么大问题的。 加密分为两大类： 对称加密，常见算法有DES、3DES、AES等等，据说AES是比较屌的最新最常用的算法非对称加密，RSA、DSA、ECDH等等对称加密用粗话说就是用同一个密钥对信息加解密。比如元首要操作东线战场了，给古德里安发了一段电报，大概意思就是“你给我闪开，让我操作！立马南下打基辅！”，但是元首又怕朱可夫给看到这段消息，于是元首就用了一个强壮的密钥123456来加密这段话，然后这段话就变成akjdslfjalwjglajwg了。古德里安收到这坨乱七八糟的玩意后，用123456来解密一下，得到明文“你给我闪开，让我操作！立马南下打基辅！”，然而朱可夫由于抓破脑壳也想不到这个超级密钥123456，所以朱可夫注定一脸懵逼，最终导致基辅60万苏军被奸！但是这里面有一个问题就是元首是如何告诉古德里安私钥是123456的。 两个人提前就商量好了，1941年6月22日的前一天偷偷商量好了。。。两个人不是提前商量好的，而是古德里安到东线后，元首通过打电话、发电报、QQ、微信。。。 。。。对于朱可夫来说，如果对方采用了方案1，那么他也没啥好办法，只能等潜伏在古德里安身边的特工卧底返回123456。由于密钥被暴露了，所以必须换新的密钥，元首这会儿只能走途径2告诉古德里安新的密钥，这会儿逗逼的事情来了，如何对密钥进行加密。答案是不能，此时问题陷入到欲要加密，必先加密的矛盾中。所以，这个密钥是注定要通过明文传输了，只要是明文传输，朱可夫就一定有机会把密钥搞到手。 非对称加密就是解决这个难题而生。密钥换来换去还想不暴露，扯犊子。还是元首和古德里安，这会儿他俩分别生成一对自己的公钥和私钥。这里需要强调的是： 公钥和私钥是成双成对生成的，二者之间通过某种神秘的数学原理连接着，具体是啥，我也不知道公钥加密的数据，只能通过相应的私钥解密；私钥加密的数据，只能通过对应的公钥解密公钥可以颁发给任何人，然而私钥你自己偷偷摸摸藏到自己裤裆里，别弄丢了这会儿就简单了，元首把自己公钥给古德里安，然后古德里安把自己公钥给元首，然后都偷偷摸摸保存好自己的私钥。有一天，元首告诉古德里安“你丫别干了，天天不听我操作！”，然后用古德里安颁发的公钥加密好了，然后让空军到东线直接仍传单，扔的满地都是，古德里安看到后从裤裆里拿出自己的私钥解密，然后就立马请假回家休息了，回去前用元首的公钥加密了如下消息“傻逼，老子还不伺候了！”，然后让空军回去撒了柏林一地，元首看到后从裤裆里拿出自己的私钥一解密：“卧槽。。。”。虽然这双方都是大大咧咧的发传单，但是朱可夫只能在旁边一脸懵逼、生无可恋。因为用于解密的私钥从来不会在外流通，所以，泄露的可能性是0。 但是，有一点是值得说明，那就是无论是对称加密还是非对称加密，都顶不住用机器是强行暴力猜解私钥。一年不行两年，两年不行二十年，二十年不行一百年，总是能猜出来的，这是没有办法的一件事情。大家可以搜一搜关于768bit RSA被KO的事件，是吧。 下面我们从gayhub上扒了一个对称加密的库下来，尝试一把aes对称加密算法，地址如下： https://github.com/ivantcholakov/gibberish-aes-php直接git clone到目录中，然后测试代码如下： <?phprequire 'GibberishAES.php';$pass = '123456';$string = '你好，古德里安，我是希特勒，你赶紧给我滚回来...';GibberishAES::size(256);$encrypted_string = GibberishAES::enc( $string, $pass );$decrypted_string = GibberishAES::dec( $encrypted_string, $pass );echo PHP_EOL."加密后的：".$encrypted_string.PHP_EOL;echo "解密后的：".$decrypted_string.PHP_EOL.PHP_EOL;保存为test.php，运行一下结果如下： 然后我们将上面代码反复运行100,000次，看看耗费多长时间： require 'GibberishAES.php';$pass = '123456';$string = '你好，古德里安，我是希特勒，你赶紧给我滚回来...';GibberishAES::size(256);$start_time = microtime( true );for( $i = 1; $i <= 100000; $i++ ) { $encrypted_string = GibberishAES::enc( $string, $pass ); $decrypted_string = GibberishAES::dec( $encrypted_string, $pass );}$end_time = microtime( true );echo "一共耗时：".( $end_time - $start_time ).PHP_EOL;保存为test.php，运行一下结果如下： ...
又一年RSA大会归来。每一年参会，总会有一些不同的感悟，或是发现全球安全行业的新趋势，或是找到志同道合的新伙伴，或是看到很多人也相信我们相信的安全技术新方向。今天在回国的航班上提笔写下我的感悟和判断，希望对安全领域里的产品和技术同学们有所启发。回顾每一年RSA的主题都有寓意。2017年的主题“Power of Opportunity”，2018年的主题是“Now Matters”。2017年我印象深刻的是大家都在讨论数据智能及AI对安全的影响，所以主题讲的是机遇（Opportunity）。2018年数据安全及GDPR对产业的影响很深，大会主题便强调安全迫在眉睫，强调此时此刻。今年的主题是“Better“，也寓含全球整个安全市场的爆发和安全产品技术的成熟，大家一起to get better。1.Cloud SIEM成为云服务提供商和安全厂商的必争之地Azure和Google在RSA期间都发布了Cloud SIEM的产品，可以让用户基于云端安全能力从云上覆盖云下的业务。这意味着企业在混合云状态下，可以从一个更全局的视角来进行安全管理运营。此外，Google近日也发布了一款网络安全产品“Backstory”，堪称威胁态势版“Google”，因其“无限扩展”能力，以及使用了构造Google基础设施核心的威胁分析引擎而引人注目。同时我也发现今年各大安全厂商也将SIEM来作为自己的主打产品。基于企业各项数据通过用户行为分析（UEBA），基于设备的威胁检测，基于IP和域名告警来实现全局安全智能分析。不论是云服务提供商还是安全厂商现在都希望通过抢占SIEM(安全信息与事件管理平台)市场。我认为本质还是大家都知道在数据时代谁拥有数据就拥有更多可能。随着Cloud SIEM的成熟，也许未来企业用户会在安全管理平台内集成多家厂商的威胁检测及响应引擎来尽可能提升效果。2.创新沙盒的冠军让我们看到安全基础建设的重要性今年RSA创新沙盒的冠军Axonius。其核心优势在于解决了企业资产管理不全的痛点。Axonius可以帮助企业降低攻击面并能与其他安全产品进行联动。这个概念并不超前。我们看到在过去的一年里，无论是有广泛市场需求的数据安全领域还是机器学习及AI在安全领域的应用，安全技术上没有出现突破性/颠覆性的创新。当谈到云上安全的最佳实践，企业安全体系重要的不仅仅是梳理资产，减少攻击面。我认为更重要的是1. 建立统一的身份认证授权体系、2. 安全基线的运营、3. 全局漏洞管理、4. 默认安全流程策略、5. 敏感数据加密。这个组合拳才是整个企业安全的基石。在这些基础领域之上提升6. 威胁检测、7. 事件调查、8. 自动化响应、9.安全溯源能力才能让整个体系更稳固。3.零信任安全的背后是身份认证将成为企业新的边界今年零信任理念也是热点之一。各厂商纷纷推出各种零信任安全产品。大部分零信任安全产品的背后将身份认证作为核心，因为身份认证将成为企业新的边界。我认为随着企业使用大量的SAAS服务、移动互联网BYOD带来的影响，大量企业应用上云，原来企业安全体系以网络边界为核心的防御理念将随之变化。身份认证将成为企业新的安全边界。基于统一的身份认证，制定不同的安全策略，建立分层授权体系，全面实时的安全智能分析能力将构建未来每个企业安全的基石。4.数据安全领域蓄势待发企业越来越重视数据安全，但因为数据安全领域横跨各个安全技术领域，导致各项数据安全方案成熟度不足。过去的一年里无论是在加密计算领域，还是在SGX可信计算领域，数据安全技术还没有大的创新突破。即便是去年创新沙盒的冠军BigID仍然是以合规驱动为主。过去一年从企业数据泄漏事件来看，数据安全技术和方案还需要提升成熟度。之前数据安全领域主要以DLP（数据防泄漏）技术为主，这两年有越来越多的数据安全厂商开始把用户行为分析、数据防泄漏、数据加密、数据流分析多种技术相结合来提升数据泄漏的检测防御效果。但我认为数据安全涉及各个领域，也不仅仅依赖于检测和响应，身份认证授权也是关键。而未来待加密计算和可信计算技术的成熟，数据安全领域也会有更大的突破创新。5.DevSecOps将得到越来越多企业的重视安全工作不能总是在事中或事后，安全工作越前置企业所付出的成本越低。阿里在2005年安全体系建设初期就开始构建SDL（安全开发流程），这也有效的降低安全漏洞数量及各项安全风险。越来越多的企业已经意识到安全评估、自动化检测必须内嵌在整个产品开发生命周期中才能确保业务及代码的安全。而今年我们看到越来越多安全厂商通过黑白盒自动化检测、RASP（运行态应用防护技术）相结合来构建DevSecOps安全方案。我相信接下来的1-2年DevSecOps安全开发流程会被更多的企业接受，整体安全方案成熟性也会逐步提升。6.安全厂商产品融合趋势明显，自动化响应建立完整安全闭环安全涉及所有技术领域导致安全产品非常碎片化，安全厂商细分领域众多。例如涉及网络安全就有DDoS防御、WAF、防火墙、IPS、RASP等多款安全产品，如果在客户场景部署就像“羊肉串”。这对用户运维管理、网络稳定性、安全运营都提出了很大的挑战。今年安全厂商趋势，试图通过多个产品融合来重新定义安全产品，提供用户更完整的安全产品。这个趋势在今年各家厂商推出的产品形态上非常明显。例如原来做终端EDR的厂商尝试将DLP技术整合至产品中。当前热门的SDP（软件定义边界）领域，厂商就结合SDWAN技术打造云端All in one安全产品来给用户进行集中流量清洗及防护。Palo Alto Networks原来是以网络防火墙为核心产品的厂商。近年来通过投资并购，产品领域已成扇形扩展，已覆盖终端安全、威胁情报、XDR(云端威胁检测及响应）。整个公司战略方向很明确，希望覆盖企业全局安全管理平台，我相信SEIM产品也会不久推出。另一方面自动化响应成今年各安全厂商产品形态又一个明显的变化趋势。我们看到安全厂商的共性：统一数据收集/ 全局威胁检测/ 自动化事件调查 /自动化响应几乎大部分Top安全厂商都在努力实现这样的完整安全闭环。前几年大家都很关注安全的Visibility，因此态势感知成为安全焦点。但是检测、Visibility能力只是原来的痛点，今年各大厂商产品都在往自动化响应闭环发展。当然这也对安全智能、事件关联分析技术和产品API化提出更高的要求。7.云安全成为最热焦点今年42%安全厂商涉及云安全，云安全成为各厂商最热点话题。主要原因是越来越多厂商推出“云安全产品”，基于本地化部署的系统上传安全数据至云端进行分析，共享云端威胁情报的能力，从而提供精准的安全决策。我还发现多家MSSP（安全服务提供商）推出基于多云的安全管理平台，可以集成AWS、Azure云安全中心的威胁检测结果，也可以集成各家安全厂商产品数据结果，最终用户可以在混合云的情况下，实现安全一站式的管理，统一安全视角。随着企业越来越多的上云，如何通过数据及AI的能力解决原来企业安全痛点，是各家厂商努力的方向。另外有一点非常有意思，海外的安全厂商几乎没有私有云的安全解决方案，云安全产品主要面向各家公共云场景。这个是当前云计算发展国内与海外最大的不同。8.构建基于API的安全生态我认为海外安全厂商的产品默认API化做的很好，可以方便给其他安全厂商进行集成，也让企业用户易于整合管理。这是海外和国内安全厂商差异所在。海外安全厂商专注在一个技术点的公司比比皆是，而国内安全公司大部分产品策略是以做多做全为主。我相信这其中也体现了国内市场和厂商的无奈。所以国外安全厂商产品天然需要和其他安全产品进行整合，自身产品就非常重视API化。随着云安全不断发展，云服务提供商和安全厂商也开始进行融合。当前全球多家安全厂商通过云产品API来构建基于云平台的安全产品。云服务提供商也集成安全厂商的API来提供云安全产品服务更多的用户。云服务提供商的安全产品API也被安全厂商集成到线下产品来提升能力。我相信用户最终需要的是能够集成各家核心安全能力，打造最佳的防御体系来应对网络安全对业务所带来的风险。9.安全厂商的品牌价值凸显如果说技术代表的是厂商的核心竞争力，那品牌展示则更清晰表达出其定位和差异化。我收集了一些安全厂商的标语，这些标语里面也体现了各家安全厂商的核心优势、品牌理念及市场定位。例如Chronicle强调安全智能、McAfee强调协同、VMware强调云原生安全和智能、AWS强调云上能够提升企业安全性。我个人更喜欢IBM Security的标语：“我们并不需要更多的安全工具，我们需要新的安全规则”。我相信互联网安全环境越来越好也一定离不开政策、法律、合作、技术创新。Chronicle : Global Secruity Intelligence （全球化的安全智能）；IBM Security： We don’t need more tools. We need new rules （不安全的世界，需要的并不是更多的安全工具，而是新的安全规则）；McAfee : Together is Power（产品协同，所有人齐心协力才是最大的力量）；VMware： Intrinsic Security，Intelligent Protection（原生安全，智能保护）；AWS ： Elevate the security（云上提升安全性）。10.展望其他安全技术领域1、在今年RSA大会上业务风控的公司不多，主要以防Bot厂商为主。但我相信随着黑灰产的发展，黑产变现方式不止局限于DDoS攻击、挖矿这类事件。未来黄牛党、广告点击欺诈、防撞库等业务安全问题会对企业业务有更多影响，而业务安全领域也将逐渐成为安全市场主流需求。2、随着Cloud SEIM的兴起以及这两年部分厂商推出MDR（可管理的检测及响应服务），我相信MSSP（安全托管服务）会被越来越多的用户所接受。而这个前提条件就是安全SAAS服务的兴起，国内目标在SAAS服务上用户接受度还不足，我预期随着云计算的发展接下来几年一定会有更大的爆发。3、今年IoT和移动安全厂商非常少，尤其是过去几年大家都很看好的IoT安全领域。这也说明整个IoT市场还在混沌阶段，我也相信IoT安全市场发展要取决于IoT OS之战。从移动互联网走到云时代再到IoT万物互联的时代，不同时代操作系统的安全水位决定了安全市场的大小和走向。我也期待着在云计算和万物互联时代真正到来时，我们能让用户及企业在互联网上更安全无忧的发展业务，帮助他们服务全球用户。本文作者：云安全专家阅读原文本文为云栖社区原创内容，未经允许不得转载。
本文由云+社区发表作者：mariolu一、什么是PSS模式？1.1、两种签名方式之一RSA-PSSPSS (Probabilistic Signature Scheme)私钥签名流程的一种填充模式。目前主流的RSA签名包括RSA-PSS和RSA-PKCS#1 v1.5。相对应PKCS（Public Key Cryptography Standards）是一种能够自我从签名，而PSS无法从签名中恢恢复原来的签名。openssl-1.1.x以后默认使用更安全的PSS的RSA签名模式。1.2、填充的必要性RSA算法比较慢，一般用于非对称加密的private key签名和public key验证。因RSA算法沒有加入乱数，当出现重复性的原始资料，攻击者会通过相同加密密文而猜测出原文，因此导入padding的机制來加強安全性。TLS流程中的密钥材料若不进行填充而直接加密，那么显然相同的key，会得到相同的密文。这种在语义上来说，是不安全的。以下例子说明了无填充模式的安全漏洞。m：明文e，n：RSA参数（公钥）d：RSA参数（私钥）c：网络传输密文加密方加密m：c = m^e mod n，传输c解密方解密c：m = c^d mod n，还原mc’：篡改密文k：篡改码由于c在网络上传输，如果网络上有人对其进行c’ = ck^e mod n，这样的替换那么解密方将得到的结果是(ck^e)^d mod n= （c^d mod n）* （k^ed mod n）= m*k即中间人有办法控制m。1.3、PSS的基本要素使用PSS模式的RSA签名流程如下：图1、RSA-PSS的填充模式相比较PKCS#1 v1.5的padding简单许多：图2、RSA-PKCS#v1.5的填充模式PSS的一些概念：hash算法，一般使用SHA-1MGF函数（mask generation function)。默认是MGF1。salt length，一般由hLen决定。当为0时，签名值变成了唯一确定的。截断符号，一般是0xbc二、RSA签名实际操作这节例子中所涉及到的文件说明：/tmp/wildcard_domain.sports.qq.com.v2.key：私钥/tmp/pub: 公钥/tmp/data: 明文/tmp/endata: 密文/tmp/sign: 签名/tmp/de_sign: 解签名2.1、前期准备：公钥和私钥通过key文件提取出public keyopenssl rsa -in /usr/local/services/ssl_agent/ca/wildcard_domain.sports.qq.com.v2.key -pubout -out /tmp/pub原始数据：echo -n “1234567890” > /tmp/data这样就有一对公钥和私钥，用来测试RSA加密解密（encrypt、decrypt）和签名验证（sign，verify）RSA加密的两种算法分别是RSAES-PKCS-v1_5 and RSAES-OAEP。2.2、加密和解密（encrypt，decrypt）加密：openssl rsautl -pubin -inkey /tmp/data -in /tmp/data -encrypt -out /tmp/endata解密，用private key解密，得到原本的值：openssl rsautl -inkey /tmp/wildcard_domain.sports.qq.com.v2.key -in /tmp/en_data -decrypt2.3、签名和验证（sign, verify）签名过程包括hash和加密。hash函数一般使用sha1。这样输入明文，直接生成sign签名。如果是私钥签名所做的事就是先hash再加密，选择一种hash算法把原始消息计算后成ASN1格式，再把这个资料用private key加密后送出，资料本身不加密，这种方式主要是用來验证资料来源是否可信任的，送出時把原始资料和签名一起送出。签名：openssl sha1 -sign /tmp/wildcard_domain.sports.qq.com.v2.key /tmp/data > /tmp/data/sign/tmp/data/sign解开签名：openssl rsautl -pubin -inkey /tmp/pub -in sign -verify -out /tmp/de_sign 用public key解开签名，并且保留padding openssl rsautl -pubin -inkey /tmp/pub -in /tmp/sign -encrypt -raw -hexdump使用解开ASN1解开签名，或者签名后用ASN1工具解析openssl rsautl -pubin -inkey /tmp/pub -in /tmp/sign -verify -asn1parse或者：openssl asn1parse -inform der -in /tmp/de_sign和本地sha1对比openssl sha1 /tmp/data如果两者hash结果是一样，那么确定签名送过来是正确的。2.4、openssl rsautl工具支持的填充模式openssl rsautl –help，可以看到支持的padding模式有，在rsautl加上以下选项可以重复做2.2~2.3的实验。 -ssl Use SSL v2 padding -raw Use no padding -pkcs Use PKCS#1 v1.5 padding (default) -oaep Use PKCS#1 OAEP三、PSS填充模式的特点PSS是RSA的填充模式中的一种。完整的RSA的填充模式包括：RSA_SSLV23_PADDING（SSLv23填充）RSA_NO_PADDING（不填充）RSA_PKCS1_OAEP_PADDING （RSAES-OAEP填充，强制使用SHA1，加密使用）RSA_X931_PADDING（X9.31填充，签名使用）RSA_PKCS1_PSS_PADDING（RSASSA-PSS填充，签名使用）RSA_PKCS1_PADDING（RSAES-PKCS1-v1_5/RSASSA-PKCS1-v1_5填充，签名可使用）其中主流的填充模式是PKCS1和PSS模式。PSS的优缺点如下：PKCS#1 v1.5比较简易实现，但是缺少security proof。PSS更安全，所以新版的openssl-1.1.x优先使用PSS进行私钥签名（具体在ssl握手的server key exchange阶段）此文已由腾讯云+社区在各渠道发布获取更多新鲜技术干货，可以关注我们腾讯云技术社区-云加社区官方号及知乎机构号 ...
lumen为速度而生的 Laravel 框架官网的介绍很简洁，而且 lumen 确实也很简单，我在调研了 lumen 相关组件（比如缓存，队列，校验，路由，中间件和最重要的容器）之后认为已经能够满足我目前这个微服务的需求了。任务目标因为业务需求，需要在内网服务B中获取到公网服务A中的数据，但是B服务并不能直接对接公网，于是需要开发一个relay 中转机来完成数据转存和交互。任务列表环境准备 【done】RSA数据加密 【done】guzzle请求封装 【done】添加monolog日志RocketMQ java请求转发程序数据库migrateEvent和Listener的业务应用Scheduler计划任务（基于crontab）Jobs和Queue业务应用使用supervisor守护queue进程和java进程添加sentry来获取服务日志信息和实现邮件报警jwt用户身份校验.env 文件的配置可能的扩展 K8S docker性能并发测试环境准备机器是centos6.8, 使用work用户, 安装 php(^7),mysql,nginx,redisyum 安装的同学可以试试 https://www.softwarecollectio…安装composerhttps://getcomposer.org/downl…# 注意php的环境变量php -r “copy(‘https://getcomposer.org/installer', ‘composer-setup.php’);“php -r “if (hash_file(‘sha384’, ‘composer-setup.php’) === ‘93b54496392c062774670ac18b134c3b3a95e5a5e5c8f1a9f115f203b75bf9a129d5daa8ba6a13e2cc8a1da0806388a8’) { echo ‘Installer verified’; } else { echo ‘Installer corrupt’; unlink(‘composer-setup.php’); } echo PHP_EOL;“php composer-setup.phpphp -r “unlink(‘composer-setup.php’);“mv composer.phar /usr/local/bin/composer安装lumencomposer global require “laravel/lumen-installer"composer create-project –prefer-dist laravel/lumen YOURPROJECT配置 .env配置Lumen 框架所有的配置信息都是存在 .env 文件中。一旦 Lumen 成功安装，你同时也要 配置本地环境。应用程序密钥在你安装完 Lumen 后，首先需要做的事情是设置一个随机字符串到应用程序密钥。通常这个密钥会有 32 字符长。 这个密钥可以被设置在 .env 配置文件中。如果你还没将 .env.example 文件重命名为 .env，那么你现在应该去设置下。如果应用程序密钥没有被设置的话，你的用户 Session 和其它的加密数据都是不安全的！配置nginx 和 php-fpm配置nginx的serverserver { listen 8080; server_name localhost; index index.php index.html index.htm; root /home/work/YOURPROJECT/public; error_page 404 /404.html; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ .php$ { root /home/work/YOURPROJECT/public; fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; #include fastcgi.conf; }}php-fpm的监听端口推荐一篇文章：Nginx+Php-fpm运行原理详解lumen 基础介绍lumen的入口文件是 public/index.php，在nginx配置文件中已有体现初始化核心容器是 bootstrap/app.php 它做了几件非常重要的事情加载了 composer的 autoload 自动加载创建容器并可以选择开启 Facades 和 Eloquent (建议都开启，非常方便)Register Container Bindings：注册容器绑定 ExceptionHandler（后面monolog和sentry日志收集用到了） 和 ConsoleKernel（执行计划任务）Register Middleware：注册中间件，例如auth验证： $app->routeMiddleware([‘auth’ => AppHttpMiddlewareAuthenticate::class,]);注册Service Providers$app->register(App\Providers\AppServiceProvider::class);$app->register(App\Providers\AuthServiceProvider::class);$app->register(App\Providers\EventServiceProvider::class);在AppServiceProvider 里还能一起注册多个provider// JWT$this->app->register(\Tymon\JWTAuth\Providers\LumenServiceProvider::class);// redis$this->app->register(\Illuminate\Redis\RedisServiceProvider::class);// 方便IDE追踪代码的Helper，因为laravel使用了大量的魔术方法和call方法以至于，对IDE的支持并不友好，强烈推荐开发环境安装$this->app->register(\Barryvdh\LaravelIdeHelper\IdeHelperServiceProvider::class);// sentry$this->app->register(\Sentry\SentryLaravel\SentryLumenServiceProvider::class);加载route文件 routes/web.php//localhost:8080/test 调用app/Http/Controllers/Controller.php的 test方法$router->get("/test”, [‘uses’ => “Controller@test”]);// 使用中间件进行用户校验$router->group([‘middleware’ => ‘auth:api’], function () use ($router) { $router->get(’/auth/show’, ‘AuthController@getUser’);});还可以添加其他初始化控制的handler，比如说这个 monolog日志等级和格式，以及集成sentry的config$app->configureMonologUsing(function(Monolog\Logger $monoLog) use ($app){ // 设置processor的extra日志信息等级为WARNING以上，并且不展示Facade类的相关信息 $monoLog->pushProcessor(new \Monolog\Processor\IntrospectionProcessor(Monolog\Logger::WARNING, [‘Facade’])); // monolog 日志发送到sentry $client = new Raven_Client(env(‘SENTRY_LARAVEL_DSN’)); $handler = new Monolog\Handler\RavenHandler($client); $handler->setFormatter(new Monolog\Formatter\LineFormatter(null, null, true, true)); $monoLog->pushHandler($handler); // 设置monolog 的日志处理handler return $monoLog->pushHandler( (new Monolog\Handler\RotatingFileHandler( env(‘APP_LOG_PATH’) ?: storage_path(’logs/lumen.log’), 90, env(‘APP_LOG_LEVEL’) ?: Monolog\Logger::DEBUG) )->setFormatter(new \Monolog\Formatter\LineFormatter(null, null, true, true)) );});配置文件 config/ 和 .env 文件其他目录文件用到时再具体说明RSA数据加密因为业务中包含部分敏感数据，所以，数据在传输过程中需要加密传输。选用了RSA非对称加密。借鉴了 PHP 使用非对称加密算法（RSA）但由于传输数据量较大，加密时会报错，所以采用了分段加密连接和分段解密php使用openssl进行Rsa长数据加密(117)解密(128)如果选择密钥是1024bit长的（openssl genrsa -out rsa_private_key.pem 1024），那么支持加密的明文长度字节最多只能是1024/8=128byte；如果加密的padding填充方式选择的是OPENSSL_PKCS1_PADDING（这个要占用11个字节），那么明文长度最多只能就是128-11=117字节。如果超出，那么这些openssl加解密函数会返回false。分享一个我的完成版的工具类openssl genrsa -out rsa_private_key.pem 1024//生成原始 RSA私钥文件openssl pkcs8 -topk8 -inform PEM -in rsa_private_key.pem -outform PEM -nocrypt -out private_key.pem//将原始 RSA私钥转换为 pkcs8格式openssl rsa -in rsa_private_key.pem -pubout -out rsa_public_key.pem<?phpnamespace App\Lib\Oscar;class Rsa{ private static $PRIVATE_KEY = ‘—–BEGIN RSA PRIVATE KEY—–xxxxxxxxxxxxx完整复制过来xxxxxxxxxxxxxxxxxxx—–END RSA PRIVATE KEY—–’; private static $PUBLIC_KEY = ‘—–BEGIN PUBLIC KEY—–xxxxxxxxxxxxx完整复制过来xxxxxxxxxxxxxxxxxxx—–END PUBLIC KEY—–’; /** * 获取私钥 * @return bool|resource / private static function getPrivateKey() { $privateKey = self::$PRIVATE_KEY; return openssl_pkey_get_private($privateKey); } /* * 获取公钥 * @return bool|resource / private static function getPublicKey() { $publicKey = self::$PUBLIC_KEY; return openssl_pkey_get_public($publicKey); } /* * 私钥加密 * @param string $data * @return null|string / public static function privateEncrypt($data = ‘’) { if (!is_string($data)) { return null; } $EncryptStr = ‘’; foreach (str_split($data, 117) as $chunk) { openssl_private_encrypt($chunk, $encryptData, self::getPrivateKey()); $EncryptStr .= $encryptData; } return base64_encode($EncryptStr); } /* * 公钥加密 * @param string $data * @return null|string / public static function publicEncrypt($data = ‘’) { if (!is_string($data)) { return null; } return openssl_public_encrypt($data,$encrypted,self::getPublicKey()) ? base64_encode($encrypted) : null; } /* * 私钥解密 * @param string $encrypted * @return null / public static function privateDecrypt($encrypted = ‘’) { $DecryptStr = ‘’; foreach (str_split(base64_decode($encrypted), 128) as $chunk) { openssl_private_decrypt($chunk, $decryptData, self::getPrivateKey()); $DecryptStr .= $decryptData; } return $DecryptStr; } /* * 公钥解密 * @param string $encrypted * @return null */ public static function publicDecrypt($encrypted = ‘’) { if (!is_string($encrypted)) { return null; } return (openssl_public_decrypt(base64_decode($encrypted), $decrypted, self::getPublicKey())) ? $decrypted : null; }}使用tip// 私钥加密则公钥解密，反之亦然$data = \GuzzleHttp\json_encode($data);$EncryptData = Rsa::privateEncrypt($data);$data = Rsa::publicDecrypt($EncryptData);guzzle使用安装超简单 composer require guzzlehttp/guzzle:~6.0guzzle 支持PSR-7 http://docs.guzzlephp.org/en/…官网的示例也很简单，发个post自定义参数的例子use GuzzleHttp\Client;$client = new Client();// 发送 post 请求$response = $client->request( ‘POST’, $this->queryUrl, [ ‘form_params’ => [ ‘req’ => $EncryptData ]]);$callback = $response->getBody()->getContents();$callback = json_decode($callback, true);guzzle支持 异步请求// Send an asynchronous request.$request = new \GuzzleHttp\Psr7\Request(‘GET’, ‘http://httpbin.org’);$promise = $client->sendAsync($request)->then(function ($response) { echo ‘I completed! ’ . $response->getBody();});$promise->wait();值的注意的是github上有一个很好玩的项目 https://github.com/kitetail/zttp它在guzzle的基础上做了封装，采用链式调用$response = Zttp::withHeaders([‘Fancy’ => ‘Pants’])->post($url, [ ‘foo’ => ‘bar’, ‘baz’ => ‘qux’,]);$response->json();// => [// ‘whatever’ => ‘was returned’,// ];$response->status();// int$response->isOk();// true / false#如果是guzzle 则需要更多的代码$client = new Client();$response = $client->request(‘POST’, $url, [ ‘headers’ => [ ‘Fancy’ => ‘Pants’, ], ‘form_params’ => [ ‘foo’ => ‘bar’, ‘baz’ => ‘qux’, ]]);json_decode($response->getBody());高可用问题思考数据传输量过大可能导致的问题RSA加密失败请求超时数据库存储并发列队失败重试和堵塞数据操作日志监控和到达率监控未完待续….. ...
python 实现私钥加密公钥解密业界普遍的用法是公钥用来加密，私钥来解密，许多人却不知道也可以用私钥加密，公钥来解密基础知识对称加密非对称加密公私钥的几个常见格式图片来源： https://www.openssl.org/docs/…使用私钥加密待编辑使用公钥解密参考文档：https://www.cnblogs.com/masak…https://www.linuxidc.com/Linu...from rsa import PublicKey, common, transform, core# 公钥格式如下，若公钥已经是 RSAPublicKey 格式，则无需将 pub key 转换为 stringPUB_KEY_STRING = ‘MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCsKfRext58G0buLDabQQNBVWEB1/B62PapiZ2tSiITw/3X4cI00QB6m7dryMqs7pKntUD3MTGeMCj9zwXX0kmqkrA8og0H0eOHQnAeuw671lkSVYnD1YVcICPv+fbJ1JL+DP3RkXuy0+V2iQC2GDQmfgTcKVowU4c+ToQIp0pUBQIDAQAB’class DecryptByPublicKey(object): """ 使用 publib key来解密用primary key加密后生成的base64类型的密文 返回解密后的数据 """ def init(self, encrypt_text): self.encrypt_text = encrypt_text @staticmethod def str2key(s): # 对字符串解码, 解码成功返回 模数和指数 b_str = base64.b64decode(s) if len(b_str) < 162: return False hex_str = ’’ # 按位转换成16进制 for x in b_str: h = hex(ord(x))[2:] h = h.rjust(2, ‘0’) hex_str += h # 找到模数和指数的开头结束位置 m_start = 29 * 2 e_start = 159 * 2 m_len = 128 * 2 e_len = 3 * 2 modulus = hex_str[m_start:m_start + m_len] exponent = hex_str[e_start:e_start + e_len] return modulus,exponent @staticmethod def f(cipher, PUBLIC_KEY): """ decrypt msg by public key """ public_key = PublicKey.load_pkcs1(PUBLIC_KEY) encrypted = transform.bytes2int(cipher) decrypted = core.decrypt_int(encrypted, public_key.e, public_key.n) text = transform.int2bytes(decrypted) if len(text) > 0 and text[0] == ‘\x01’: pos = text.find(’\x00’) if pos > 0: return text[pos+1:] else: return None def pub_decrypt_with_pubkeystr(self): """ 将 base64 编码的 pub_key 转成 bio 对象, 再将bio对象转换成公钥对象 """ # 将 pub key 转换为 string # Note: 若公钥已经是 RSAPublicKey 格式，则无需执行这一步 ！ try: key = self.str2key(PUB_KEY_STRING) # 将 base64 编码的公钥进行拆解，取出模数和指数 if not key: raise Exception, “decode public key falid” modulus = int(key[0], 16) exponent = int(key[1], 16) rsa_pubkey = PublicKey(modulus, exponent) # 根据模数和指数生成 pubkey 对象 self.pub_key = rsa_pubkey.save_pkcs1() # 将 pubkey 对象导出为 RSAPublicKey 格式的公钥 except Exception, e: assert False, “Invalid public_key” # 开始解密 try: ret = self.f(self.encrypt_text.decode(“base64”), self.pub_key) except Exception, e: self.error_info = str(e) assert False, “Decrypt by public key fails! Invalid encrypt_text” return retif name == “main”: encrypt_text = ‘xxxxxx’ # encrypt_text 是被私钥加密后的密文 decrypt = DecryptByPublicKey(encrypt_text) result = decrypt.pub_decrypt_with_pubkeystr() print result ...
密码学是在编码与破译的斗争实践中逐步发展起来的,并随着先进科学技术的应用，已成为一门综合性的尖端技术科学。密码学发展史在说RSA加密算法之前， 先说下密码学的发展史。其实密码学的诞生，就是为了运用在战场，在公元前，战争之中出现了秘密书信。在中国历史上最早的加密算法的记载出自于周朝兵书《六韬.龙韬》中的《阴符》和《阴书》。在遥远的西方，在希罗多德（Herodotus）的《历史》中记载了公元前五世纪，希腊城邦和波斯帝国的战争中，广泛使用了移位法进行加密处理战争通讯信息。相传凯撒大帝为了防止敌人窃取信息，就使用加密的方式传递信息。那么当时的加密方式非常的简单，就是对二十几个罗马字母建立一张对照表，将明文对应成为密文。那么这种方式其实持续了很久。甚至在二战时期，日本的电报加密就是采用的这种原始加密方式。早期的密码学一直没有什么改进，几乎都是根据经验慢慢发展的。直到20世纪中叶，由香农发表的《秘密体制的通信理论》一文，标志着加密算法的重心转移往应用数学上的转移。于是，逐渐衍生出了当今重要的三类加密算法：非对称加密、对称加密以及哈希算法（HASH严格说不是加密算法，但由于其不可逆性，已成为加密算法中的一个重要构成部分）。1976年以前，所有的加密方法都是同一种模式：加密和解密使用同样规则（简称"密钥"），这被称为"对称加密算法"，使用相同的密钥，两次连续的对等加密运算后会回复原始文字，也有很大的安全隐患。1976年，两位美国计算机学家Whitfield Diffie 和 Martin Hellman，提出了一种崭新构思，可以在不直接传递密钥的情况下，完成解密。这被称为"Diffie-Hellman密钥交换算法"。也正是因为这个算法的产生，人类终于可以实现非对称加密了：A给B发送信息B要先生成两把密钥（公钥和私钥）。公钥是公开的，任何人都可以获得，私钥则是保密的。A获取B的公钥，然后用它对信息加密。B得到加密后的信息，用私钥解密。理论上如果公钥加密的信息只有私钥解得开，那么只要私钥不泄漏，通信就是安全的。1977年，三位数学家Rivest、Shamir 和 Adleman 设计了一种算法，可以实现非对称加密。这种算法用他们三个人的名字命名，叫做RSA算法。从那时直到现在，RSA算法一直是最广为使用的"非对称加密算法"。毫不夸张地说，只要有计算机网络的地方，就有RSA算法。这种算法非常可靠，密钥越长，它就越难破解。根据已经披露的文献，目前被破解的最长RSA密钥是232个十进制位，也就是768个二进制位，因此可以认为，1024位的RSA密钥基本安全，2048位的密钥极其安全，当然量子计算机除外。RSA算法的原理下面进入正题，解释RSA算法的原理，其实RSA算法并不难，只需要一点数论知识就可以理解。素数：又称质数，指在一个大于1的自然数中，除了1和此整数自身外，不能被其他自然数整除的数。互质，又称互素。若N个整数的最大公因子是1，则称这N个整数互质。模运算即求余运算。“模”是“Mod”的音译。和模运算紧密相关的一个概念是“同余”。数学上，当两个整数除以同一个正整数，若得相同余数，则二整数同余。欧拉函数任意给定正整数n，请问在小于等于n的正整数之中，有多少个与n构成互质关系？（比如，在1到8之中，有多少个数与8构成互质关系？）计算这个值的方法就叫做欧拉函数，以(n)表示。计算8的欧拉函数，和8互质的 1、2、3、4、5、6、7、8(8) = 4如果n是质数的某一个次方，即 n = p^k (p为质数，k为大于等于1的整数)，则(n) = (p^k) = p^k - p^(k-1)。也就是(8) = (2^3) =2^3 - 2^2 = 8 -4 = 4计算7的欧拉函数，和7互质的 1、2、3、4、5、6、7(7) = 6如果n是质数，则 (n)=n-1 。因为质数与小于它的每一个数，都构成互质关系。比如5与1、2、3、4都构成互质关系。计算56的欧拉函数(56) = (8) (7) = 4 6 = 24如果n可以分解成两个互质的整数之积，即 n = p k ，则(n) = (p k) = (p1)(p2)欧拉定理：如果两个正整数m和n互质，那么m的(n)次方减去1，可以被n整除。费马小定理：欧拉定理的特殊情况，如果两个正整数m和n互质，而且n为质数！那么(n)结果就是n-1。模反元素还剩下最后一个概念，模反元素：如果两个正整数e和x互质，那么一定可以找到整数d，使得 ed-1 被x整除，或者说ed被x除的余数是1。那么d就是e相对于x的模反元素。等式转换根据欧拉定理由于1^k ≡ 1，等号左右两边都来个k次方由于1 m ≡ m，等号左右两边都乘上m根据模反元素，因为ed 一定是x的倍数加1。所以如下：通过多次的等式转换。终于可以将这两个等式进行合并了！如下：这个等式成立有一个前提！就是关于模反元素的，就是当整数e和(n)互质！一定有一个整数d是e相对于(n)的模反元素。我们可以测试一下。m取值为4n取值为15(n)取值为8e 如果取值为3d 可以为 11、19…(模反元素很明显不止一个，其实就是解二元一次方程)如果你测试了，那么你可以改变m的值试一下，其实这个等式不需要m和n 互质。只要m小于n 等式依然成立。这里需要注意的是，我们可以看做 m 通过一系列运算得到结果仍然是 m。这一系列运算中，分别出现了多个参数n、(n)、e还有d。m 的 e乘上d 次方为加密运算，得到结果 cc 模以 n 为解密运算，得到结果 m这似乎可以用于加密和解密。但这样，加密的结果会非常大。明文数据将非常小（虽然RSA用于加密的数据也很小，但是没这么大悬殊），真正的RSA要更加强大，那么RSA是怎么演变来的呢？？早期很多数学家也停留在了这一步！直到1967年迪菲赫尔曼密钥交换打破了僵局！迪菲赫尔曼密钥交换这个密钥交换当时轰动了整个数学界！而且对人类密码学的发展非常重要，因为这个伟大的算法能够拆分刚才的等式。当非对称加密算法没有出现以前，人类都是用的对称加密。所以密钥的传递，就必须要非常小心。迪菲赫尔曼密钥交换 就是解决了密钥传递的保密性，我们来看一下假设一个传递密钥的场景。算法就是用3 的次方去模以17。 三个角色服务器 随机数 15这个15只有服务器才知道。通过算法得到结果 6 因为 3的15次方 mod 17 = 6 。然后将结果 6 公开发送出去，拿到客户端的 12 ，然后用12^15 mod 17 得到结果10(10就是交换得到的密钥)客户端 随机数13客户端用3 的 13次方 mod 17 = 12 然后将得到的结果12公布出去。拿到服务器的 6 ，然后用6^13 mod 17 得到结果10(10就是交换得到的密钥)第三者第三者只能拿到6 和 12 ，因为没有私密数据13、15，所以它没法得到结果10。为什么 6的13次方会和12的15次方得到一样的结果呢?因为这就是规律，我们可以用小一点的数字测试一下3^3 mod 17 = 10和10 ^ 2 mod 17 ； 3 ^ 2 mod 17 = 9和9^3 mod 17结果都是15。迪菲赫尔曼密钥交换最核心的地方就在于这个规律RSA的诞生现在我们知道了m^e % n = c是加密，c^d % n = m是解密，m就是原始数据，c是密文，公钥是n和e，私钥是n和d，所以只有n和e是公开的。加密时我们也要知道(n)的值，最简单的方式是用两个质数之积得到，别人想破解RSA也要知道(n)的值，只能对n进行因数分解，那么我们不想m被破解，n的值就要非常大，就是我们之前说的，长度一般为1024个二进制位，这样就很安全了。但是据说量子计算机(用于科研，尚未普及)可以破解，理论上量子计算机的运行速度无穷快，大家可以了解一下。以上就是RSA的数学原理检验RSA加密算法我们用终端命令演示下这个加密、解密过程。假设m = 12(随便取值，只要比n小就OK)，n = 15(还是随机取一个值)，(n) = 8，e = 3(只要和(n)互质就可以)，d = 19（3d - 1 = 8，d也可以为3,11等等，也就是d = (8k + 1)/3 ）终端分别以m=12，7输入结果OpenSSL进行RSA的命令运行Mac可以直接使用OpenSSL，首先进入相应文件夹生成公私钥// 生成RSA私钥，文件名为private.pem，长度为1024bitopenssl genrsa -out private.pem 1024// 从私钥中提取公钥openssl rsa -in private.pem -pubout -out publick.pem// 查看刚刚生成好的私钥cat private.pem// 查看刚刚生成好的公钥cat publick.pem我们可以看到base64编码，明显私钥二进制很大，公钥就小了很多。这时候我们的文件夹内已经多了刚刚生成好的公私钥文件了// 将私钥转换为明文openssl rsa -in private.pem -text -out private.txt里面就是P1、P2还有KEY等信息。对文件进行加密、解密// 编辑文件message内容为hello Vincent!!!// 刚刚的public.pem写成了publick.pem(哎。。。) $ vi message.txt $ cat message.txt hello Vincent!!!// 通过公钥加密数据时，使用encrypt对文件进行加密 $ openssl rsautl -encrypt -in message.txt -inkey publick.pem -pubin -out enc.txt// 此时查看该文件内容为乱码 $ cat enc.txtj��E]a��d�kUE�&< ��I��V/��pL[����O�+�-�M��K��&⪅O��2���o34�:�$���6��C�L��,b�‘M�S�k�0���A��3%�[I���1�����ps"%// 通过私钥解密数据 $ openssl rsautl -decrypt -in enc.txt -inkey private.pem -out dec.txt// 已成功解密，正确显示文件内容 $ cat dec.txt hello Vincent!!!// 通过私钥加密数据时，要使用sign对文件进行重签名$ openssl rsautl -sign -in message.txt -inkey private.pem -out enc.bin// 此时查看该文件内容同样为乱码$ cat enc.bin{���Ew�3�1E��,8-OA2�Is�:���:�@MU���� �i1B���#��6���m�D(�t#/��� ��������>(�>�^@�C��3�MQ�O%// 通过公钥解密数据$ openssl rsautl -verify -in enc.bin -inkey publick.pem -pubin -out dec.bin// 已成功解密，正确显示文件内容$ cat dec.bin hello Vincent!!!RSA用途及特点到这里，大家都知道RSA通过数学算法来加密和解密，效率比较低，所以一般RSA的主战场是加密比较小的数据，比如对大数据进行对称加密，再用RSA给对称加密的KEY进行加密，或者加密Hash值，也就是数字签名。关于RSA数字签名后面再慢慢阐述。该文章为记录本人的学习路程，希望能够帮助大家，也欢迎大家点赞留言交流！！！https://www.jianshu.com/p/ad3… ...