@dzdh 后者 secp256r1 是 SSL RFC 规范里必选曲线，前者 secp256k1 只不过是可选项，谁优谁劣很早就有定论。
所谓 magic number 只不过有些人不信 gov 发布的曲线，怀疑有后门，但这个和我们普通老百姓一点关系都没有。
实现 HTTPS，secp256r1 就是必须支持的，而不是可要可不要。

不是一回事，两者的安全系数不一样。后者要比前者更安全。

在椭圆算法里，每一个曲线参数都有一个 OID

secp256k1 的 OID 是 1.3.132.0.10
nistp256 的 OID 和 secp256r1 一样，是 1.2.840.10045.3.1.7

名称屁股后面 k 代表着是 Koblitz(ECC 发明人), r 代表着 Random 随机数。

至于为什么 r 比 k 要安全，引用老外的一句结论：Secp256k1 could leak information for side channel attacks because the time for some calculations is not constant.

用着用着，到最后就变成了 POST 一把梭了。

我和楼主需求刚好相反，是通过子类化窗口，来给老款编辑器软件加入 Shift+滚轮=屏幕左右滑动的功能。
已经习惯了 VSCODE 的快速左右划屏，一行 HTML 代码一多，不用浑身变扭，回不去了。

@LeeReamond 我 win10 的版本比较老，可能和楼上回复综合一下，删掉"Extended"=""那句？

@abersheeran 原来是这样。
我个人觉得女生比较复杂，至少比技术男复杂多了。
论坛上她们一般只会发帖求认同，一旦不认同的人数多了，马上会删帖。炫耀嫉妒讲故事，样样都比男人厉害。
女人心，海底针，一点都不假。

还好啦，论坛大部分人是来斗嘴，小部分人是来交流技术。真学技术的，早就自己查 Google，翻 Github 了。
要以不改变对方想法为前提，和善的交流，就不会那么心累。你看我昨天回复的那个长贴就知道了，尽管那么多人反对，也丝毫不能动摇楼主的个人想法。
人始终是需要一个情绪出口的，就当 V2 是一个闲聊区，也挺好的。

我的注册表，参考一下：
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Directory\Background\shell\OpenCmdHere]
@="Open command window here"
"Extended"=""
"NoWorkingDirectory"=""

[HKEY_CLASSES_ROOT\Directory\Background\shell\OpenCmdHere\command]
@="PowerShell -windowstyle hidden -Command \"Start-Process cmd.exe -ArgumentList '/s,/k, pushd,%V' -Verb RunAs\""


话说你都能上 V2 正常发帖，用什么百度哦。

换种说法，同样是银行，瑞士中央银行和普通小银行的安全系数也是不一样的。
“系统够不够安全”，完全取决于要保护东西的价值有多大。
有些东西可以丢，有些东西丢不起。

@dzdh "客户玩了命的作死没有什么方案可以达到『足够安全』的标准。"

客户明明是上帝，你怎么能说客户作死呢。互联网就是适者生存的竞争环境，是你去主动适应客户，而不是让客户来反向适应你。

换成我设计支付 API，如果客户的网络不可信，那就直接接管客户那头所有的收发代码。在发布的 SDK JS 里套一层额外虚拟机，用自己的流程和加密算法来处理所有敏感数据，这样哪怕客户的 TLS 解密网关保存了明文数据包，照样没办法轻易解读。

就算未来资金支付出错被盗，那也不能怪客户。一般都是码农站出来背锅，就从来没听说过让客户背锅的。

可能有人不了解 RSA 具体算法，我多罗嗦几句。

RSA 官方有 RFC 3447 使用规范，规定了 RSA 签名算法和 RSA 加密算法，是两套不同的 schemes 。

两者最大区别是，用 RSA 签名算法处理的数据，每次密文都是一样的。而用 RSA 加密算法处理的数据，每次都是不一样的（为了确保破解者的难度，每次加密后的密文都会变）

不幸的是，地球最强加密算法，RSA 加密算法并没有在 HTTPS 里使用，也没有任何能开启的方法。原因不明，反正就是没用 RFC 规定的那一套加密流程。仅仅用了一下公钥私钥的验证流程。

如果你们谁在 HTTP 处理流程里，加入了 RFC 提到的 RSA 加密算法，对内容重加密，那恭喜你，先不讨论 JS 的安全性，光加密后数据的安全性，已经超过了 HTTPS 。

@dzdh "就说 RSA 算法这个本身，数学上，是不是足够安全？"

算法本身是安全的，这点不用怀疑。可是你这个系统里，又不是用 RSA 来加密内容的。

HTTPS 是用 RSA 做签名验证，仅仅只加密了握手阶段的密钥，而内容本身的加密部分，是 AES 这种对称式加密处理。为什么？因为 RSA 性能有问题，一次只能加密一小部分内容，全部加密 CPU 抗不住。

如果 RSA 加密和 AES 加密对比，无疑 RSA 安全性要胜出一截，关键 HTTPS 并不是全程 RSA 加密啊。

再者，你能确保自己的服务器上 HTTPS 通道万无一失，却没办法保证客户 HTTPS 通道没有任何问题。我上面回复过了，HTTPS End-To-End 是安全的，但也仅限为『 End-To-End 』，这个大前提，你不能无视。

@dzdh "只有合适的方案，合适的方案就是对的方案。"

用户才不管你方案是不是最合适的，资金被盗后，他只在乎你赔不赔钱。同样，你也不敢拍胸脯保证支付系统 API 设计 100%安全。也不敢和支付宝那样，宣传有用户任何金额损失，我站出来全额赔付。

如果连自己都说服不了自己，又怎么有底气去说服别人，这方案『足够的安全』？

@dzdh "怎么定义『短期』。1 天？ 1 小时？ DV 证书重新签发 1-3 分钟。"
吊销又不是签发，不可能 3 分钟生效的。

吊销的流程是通知 CA 你证书密钥掉了，然后 CA 定期发布一个 CRL 吊销列表，把你的无效证书信息写进去。然后浏览器会定期同步一次。

和商户 KEY 对比一下速度，那真是乌龟和兔子赛跑 - 龟速反应。

@dzdh "如果要『扯中间环节』那就一定要说密钥保全，这又是『客户端环境安全』的问题，我就故意泄露密钥、私钥。"

不啊，你 HTTPS 证书密钥丢了，短期内并没有什么有效补救措施。

你微信商户 KEY 泄漏，马上进入商户后台吊销 KEY，重新生成一个就可以了，瞬间生效，方便快捷又安全。

@dzdh "这不都是因为已经『足够安全了』吗？"

够不够，因人而异。我个人觉得只靠 HTTPS 是不够的。

http 签名 RFC 协议是 2020 年发布的，假设 HTTPS 真的够用，那又何必在 HTTPS 发明的那么多年后，又发布这种额外协议，多此一举。

只有真正的 HTTPS End-To-End，在我眼里才算勉强够，可事实情况并不是，中间环节总会经过各种奇怪 TLS 解密终端。

你们怎么都想到设置代理，难道楼主没有 linux 的 root 权限？
感觉要求就是把 linux 当成一个软路由，普通的 NAT 转发机器。

@dzdh 今天回复了别的帖子，右边 V2 摸鱼条已经变黄了，应该不能回复很多条了。

我的观点那么多来来回回，已经的比较清晰了。我就是觉得有必要把客户的钱当成自己的钱，你就会不自觉的把细节扣到极致。

试想一下由于忘关窗户的疏忽，晚上回家发现家里来过小偷，把你电脑和硬盘上所有的小姐姐资料全部偷走。是不是会后悔自己没有把安全防范做到极致？安全就是能把现在设想到的一切，都尽力做好，好让灾难真正发生的时候，没那么自责内疚和懊悔。