server 端和 app 客户端采用对称加密安全吗？ app 逆向能看出密钥吗？或者没有密钥能暴力破解数据吗？

看你本事啊

安不安全看你的密钥是怎么协商 /分发的了
内置静态密钥肯定是不行的
没有密钥能不能破解数据，这要看你选择的分组方式，以及有没有设计上的漏洞

app 逆向能看出密钥吗？ 能,

或者没有密钥能暴力破解数据吗？ 基本不能

@gz911122 #3 没有密钥能暴力破解数据吗？能，就看你能不能熬到出结果了

对称将在这种情况下不安全

@dorothyREN 你是指让孙子看结果的那种吗（狗头）

现场协商一个密钥出来就行了，现在所有应用都这么干的。

客户端集成公钥吧，动态协商出一个随机对称密钥

客户端首次启动时生成自己的的公钥私钥，公钥用服务器的公钥来加密，然后发给服务器，服务器用自己的私钥解密后把客户的公钥和客户 id 对应存储起来，服务器未来都通过这个私钥加密数据后再发给客户端，客户端收到数据后用自己的私钥解密，客户端未来都通过服务器的公钥来加密数据发给服务端。
可是为什么要自己来实现这些呢？ https 协议不香么？

只要对方一直能接触到客户端，只要客户端本地有加密解密的操作，那么客户端和服务端的交互的所有数据就一定能得到明文，协商密钥也没用

楼主看了楼上回复，一顿操作，写出了个 TLS

你是想防御哪个环节？

类似不知道讨论了多少次，不可能完全杜绝用户自行编写第三方客户端

如果要防止接口被灰产黑产利用，那么问题就从保护密钥转变为了机器人识别（反爬虫）和安全控制（逻辑安全）

只能密钥协商了吧。。
不过就算是密钥协商也防不了中间人攻击啊= =

1.相比于不加密肯定时安全得多；
2.逆向能找出密钥，所以 app 需要用加固防止攻击者对 app 进行调试；
3.几乎不能。

安全是相对的，没有绝对。

@liuxu 有个毛病要挑一下，ssl 的数据是对称加密

安全是相对的，首先有一点很关键， [不管你再怎么加密，对于客户端来说都是明文] ，所以 APP 逆向自然能看出密钥。

如果攻击方是可以随意操作客户端的（比如爬虫开发者），那自然不管防守方再怎么折腾都能拿到通信内容的明文；
但如果攻击方不能操作客户端（比如中间人攻击），或者是受限于比防守方可控范围更高级的权限控制（比如无法获取高权限的设备，像没有越狱的 iOS 设备之类的），那你只是一个固定密钥的 AES 之类的加密也没关系，因为人家这种情况也只能暴力破解。

建议搞清楚自己想要防的到底是什么。

@liuhan907 嗯。。。你我说的都不全面。。
ssl 前面握手是非对称，nginx 配置证书就有公钥和私钥，数据通信是对称加密，这个是请求时动态分配给的，所以逆向了 app 也拿不到

感谢各位回复，app 是 Android，目前找到了一些方案，使用 Android Keystore 可以比较安全的存储密钥，还没动手做，应该挺靠谱这个方案，server 端和 app 端使用对称加密，挺安全