1
wy315700 2015-04-07 22:05:57 +08:00
ECC 椭圆曲线。
SSL已经很快了,,,用ECC证书然后打开spdy或者keep-alive |
2
Tianpu OP 我还是使用对称加密吧 非对称开销太大 真不如使用openssl
算法使用aes-256-cbc 15k的文本 加密解密千次约0.095s 系统瓶颈应该不会是这块了 |
4
h4x3rotab 2015-04-08 00:21:36 +08:00
用非对称比如椭圆曲线传递密钥,然后用AES做实际加密
|
5
Tianpu OP |
6
ryd994 2015-04-08 04:55:04 +08:00
有长连接的情况下开销应该不大啊
|
7
efi 2015-04-08 05:04:48 +08:00
没有
|
8
NeoAtlantis 2015-04-08 05:59:40 +08:00 via Android
curve25519
|
9
lingxi27 2015-04-08 09:12:04 +08:00
SSL可以选择加密算法,自创加密机制的行为比裸奔好不了多少
|
10
wy315700 2015-04-08 09:13:26 +08:00
LZ是两台服务间吧,开启SPDY和KEE-ALIVE SSL速度很快的
|
11
zhujinliang 2015-04-08 09:33:59 +08:00 via iPhone
两服务器之间架设VPN呢
|
12
janxin 2015-04-08 16:04:27 +08:00
国密算法看文档说比RSA会快...不过我猜你们不会用...
|
13
Tianpu OP 我造了俩脚本,target.php 输出连接信息 test.php通过curl读target.php
http 0.001s- https 0.042s+ 域名解析部分都放在hosts里 两个机器是配置一样的闲时状态 也就是说https握手需要42ms 诸位看这个页面最下面 慢成渣滓的v2ex我现在看到的时间都只有49ms 一个API读取耗费这么久 实在不能忍受 所以 我再三犹豫 默认一定要是http协议来连接API 只不过返回内容加密下 加密解密加一起也用不了0.001s API和WEB同机房 延迟大致可以认为是0.2ms左右 也就是API部分最多耗费0.002秒 这样的性能损耗是可以接受的 |
15
Tianpu OP [root@v2ex temp]# curl -w "@time.txt" -o /dev/null -s https://localhost/test.php
time_namelookup: 0.000 time_connect: 0.000 time_appconnect: 0.042 time_pretransfer: 0.042 time_redirect: 0.000 time_starttransfer: 0.042 ---------- time_total: 0.042 典型的时间消耗 |
16
Tianpu OP 还有https是ssllabs a+评分的配置 应该不存在太大的改进余地了
|
18
Tianpu OP @wy315700 ECC支持不够广泛 只找到commdo支持 更重要的是 反而变成0.044s了
有更大的坑 curl 7.36才支持ECC https://bugzilla.redhat.com/show_bug.cgi?id=1058776 libcurl没有细查 坚守centos 6.x 反对systemctl 好像没有比较好多办法 我还是http裸奔吧 |
19
wanliang1221 2015-04-09 10:02:11 +08:00
直接非对称传递密钥,然后对称加密呗。
|
20
wengebin 2015-04-09 12:39:17 +08:00 1
自己用 private key 实现的加密,依旧走http协议的对称加密算法,不知道能不能帮到你,前后是这样的:
Encrypted str: BeQEmA3fAuZTyQHnVrgF8AbxVbtWxlWFWuQJyQXAUiEAZAF0AShSPFNyDmsBJFc1BmAE61TXANlU6QvCBf5W4wWOBIUNEwJDUxEBc1Y1BSAGIlUsVi9VO1ouCXsFM1J0AGABewEzUjxTPg49ASRXdAYzBGlUNgA1VHsLeAUyVmoFbwQrDSUCaFM9ASRWAgU2BiNVO1ZyVWJaZgk9BW5SaABjATwBa1JgU2cOZAE9VzEGYARhVDcANlRsCyMFI1ZpBeQEtg33AuZTzgHaVroF7wbQVbpWw1Wk Decrypted str: 有更大的坑 curl 7.36才支持ECC https://bugzilla.redhat.com/show_bug.cgi?id=1058776libcurl没有细查 Consuming time: 0.00056600570678711 s 刚顺便整理了,需要摸这里: https://github.com/woondroo/EncryptAndDecrypt_php |
21
Tianpu OP @wengebin 天 你自己造了个轮子
我测试openssl_encrypt和openssl_decrypt,算法使用aes-256-cbc 速度还行 现在的问题是https协议的话API会有42ms的损耗 如果是http协议只有1ms左右 最终实在没有办法 目前我计划是这么干的: 所有读操作 使用http协议 传输加密后的数据 所有写操作 使用https协议 传输加密后的数据 这样子的话 接口只有API地址不一样 |
22
wengebin 2015-04-09 13:34:09 +08:00
@Tianpu 你说的方式属于标准协议了,其实自起炉灶也不是坏事,在某些角度上讲,对算法稍加修改就能防止其他人的解密,在算法封闭的情况下几乎不可能破解。
这个算法是参考网游的加密通讯写的,效率上和安全上都是有参考依据的。 |
23
zhicheng 2015-04-09 13:46:20 +08:00 via Android
@wengebin 那是因为你的业务本身没有多大价值。加密算法的强度,永远都不能取决于加密算法的保密程度。
|
24
wengebin 2015-04-09 13:51:10 +08:00
@zhicheng 你说的很对,对于实时性要求更高、频率大的通讯数据来说,轻量、快速是要点,普通API完全足够,支付一类只能使用更高强度加密算法牺牲性能是对的。
|
25
free9fw 2015-04-17 11:18:35 +08:00
openssl
|