效率和性能都比较好的非对称加密算法有推荐的吗？

SSL

加密

耗费

25 条回复 • 2015-04-17 11:18:35 +08:00

1

wy315700

2015-04-07 22:05:57 +08:00

ECC 椭圆曲线。

SSL已经很快了，，，用ECC证书然后打开spdy或者keep-alive

2

Tianpu

OP

2015-04-07 23:43:07 +08:00

我还是使用对称加密吧非对称开销太大真不如使用openssl

算法使用aes-256-cbc 15k的文本加密解密千次约0.095s 系统瓶颈应该不会是这块了

3

wy315700

2015-04-07 23:48:31 +08:00

@Tianpu 你的密钥不会内置吧。。。

4

h4x3rotab

2015-04-08 00:21:36 +08:00

用非对称比如椭圆曲线传递密钥，然后用AES做实际加密

5

Tianpu

OP

2015-04-08 01:33:24 +08:00

@wy315700 打算内置啊 iv倒是动态生的

两个服务器应该认为是安全的如果两台服务器被干掉即使使用公匙/私匙也还是没用

也不是很核心的东西简单加密下能满足需要了

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

2015-04-08 22:52:19 +08:00

我造了俩脚本，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秒

这样的性能损耗是可以接受的

14

Tianpu

OP

2015-04-08 22:52:51 +08:00

@wy315700 curl折腾下应该可以支持spdy 就是后续维护麻烦

15

Tianpu

OP

2015-04-08 22:56:33 +08:00

[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

2015-04-08 23:00:10 +08:00

还有https是ssllabs a+评分的配置应该不存在太大的改进余地了

17

wy315700

2015-04-08 23:14:36 +08:00

@Tianpu 换ECC证书看看

18

Tianpu

OP

2015-04-09 01:13:44 +08:00

@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

2015-04-09 13:01:50 +08:00

@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