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

ECC 椭圆曲线。

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

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

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

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

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

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

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

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

有长连接的情况下开销应该不大啊

没有

curve25519

SSL可以选择加密算法，自创加密机制的行为比裸奔好不了多少

LZ是两台服务间吧，开启SPDY和KEE-ALIVE SSL速度很快的

两服务器之间架设VPN呢

国密算法看文档说比RSA会快...不过我猜你们不会用...

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

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

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

[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

典型的时间消耗

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

@Tianpu 换ECC证书看看

@wy315700 ECC支持不够广泛 只找到commdo支持 更重要的是 反而变成0.044s了

有更大的坑 curl 7.36才支持ECC https://bugzilla.redhat.com/show_bug.cgi?id=1058776
libcurl没有细查

坚守centos 6.x 反对systemctl 好像没有比较好多办法

我还是http裸奔吧

直接非对称传递密钥，然后对称加密呗。

自己用 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

@wengebin 天 你自己造了个轮子

我测试openssl_encrypt和openssl_decrypt，算法使用aes-256-cbc 速度还行

现在的问题是https协议的话API会有42ms的损耗 如果是http协议只有1ms左右

最终实在没有办法 目前我计划是这么干的：

所有读操作 使用http协议 传输加密后的数据
所有写操作 使用https协议 传输加密后的数据

这样子的话 接口只有API地址不一样

@Tianpu 你说的方式属于标准协议了，其实自起炉灶也不是坏事，在某些角度上讲，对算法稍加修改就能防止其他人的解密，在算法封闭的情况下几乎不可能破解。

这个算法是参考网游的加密通讯写的，效率上和安全上都是有参考依据的。

@wengebin 那是因为你的业务本身没有多大价值。加密算法的强度，永远都不能取决于加密算法的保密程度。

@zhicheng 你说的很对，对于实时性要求更高、频率大的通讯数据来说，轻量、快速是要点，普通API完全足够，支付一类只能使用更高强度加密算法牺牲性能是对的。

openssl