@sunnysab #33 我觉得可以去掉 OP 问题里的一部分无效信息，如 ARP 如 SMB 。我是这么看待的：这是个小公司，不会有安全专家，预算也低，所以建议买产品，而不是让 OP 招个人或者依赖于自身水平去配置

@sunnysab #27 没觉得跑题，你仔细说说。至于慢，有那种自己部署的产品，但我不了解。但这里讨论的是这个需求到底可不可以用零信任这个筐来装，所以性能其实不是这里的问题。其实楼上提到的很多思路不正是零信任的雏形么

@drymonfidelia #14

> 零信任解决的是外网访问内网的问题

这误解大了，要是还区分内外网，零信任还谈什么零。

随便找一家零信任产品的介绍都可以知道你这理解是错的

> Zero Trust 安全是一种 IT 安全模型，要求试图访问专用网络上资源的每一个人和每一台设备（无论位于网络边界之内还是之外）都必须进行严格的身份验证

> 零信任是一种设计安全防护架构的方法，它的核心思路是：默认情况下，所有交互都是不可信的。这与传统的架构相反，后者可能会根据通信是否始于防火墙内部来判断是否可信。具体而言，零信任力求弥合依赖隐式信任模型和一次性身份验证的安全防护架构之间的缺口。

> 零信任的網路資安徹底顛覆了舊的典範，網路資安再也不是靠著細分的網段或是企業網路邊境來維護安全。信任與否，將不再根據連線或資產是否為企業或使用者所擁有來判斷。此外，也不再根據實體位置或網路位置 (也就是位於網際網路或區域網路) 來判斷。零信任的方法是以個別的資源、使用者和資產本身為主體，而不是看它們的擁有者或所在位置。每位使用者在存取企業的每項資源之前，都必須個別通過認證。其終極目標就是：對於任何網路元素，在通過認證之前，都應保持零信任的態度。

#9 明显吗？我没觉得很明显。所以你的内网是完全离线的吗？

这个标题和内容，零信任就完全是为之诞生的

https://www.cloudflare.com/plans/zero-trust-services/ 三十人三百块钱，很低成本了吧

关闭什么功能？

> 在保存代码的时候，自动 format

"editor.formatOnSave": false

> 调整代码 include 的头文件顺序

https://stackoverflow.com/questions/64392293/c-clang-formatter-how-to-avoid-rearranging-sorting-include-blocks-at-all
https://stackoverflow.com/questions/60334299/clang-format-disable-ordering-includes

Bitcoin 中比较相关的 sha256d 是 sha256(sha256())

OP 说的拼接是 (sha256()+sha256())
https://www.google.com/search?q=site%3Acrypto.stackexchange.com+concat+hash

感觉都是很受批评或者很具争议的方式

/t/1037362

Iosevka 吧？

@geelaw #1 这翻译太谐音了

@MozzieW #4

> 也就是你猜测的 AES 的地方

我没有猜测... #3 是那个作者的注释

> 但我确定不是，因为我怀疑过这个使用了某个成熟的算法的相关逻辑，所以把 AES 、DES 等 SBox 相关的逻辑都过了一遍，没有对上的

DRM 中广泛应用白盒加密，例如该类技术最早被提出时的简介："The white-box model with initial attempts of white-box DES and AES implementations were first proposed by Chow, Eisen, Johnson and van Oorshot in 2003. The designs were based on representing the cipher as a network of lookup tables and obfuscating the tables by composing them with small (4- or 8-bit) random encodings. Such protection satisfied a property that each single obfuscated table individually does not contain any information about the secret key. Therefore, a potential attacker has to combine several tables in their analysis."

所以问题来了，如何确定这些 table 不是"混淆"后的呢？用标准的流程去对照，那肯定是很难对上的。

> ab 是四个 long 的异或，怎么还原回四个 ptr ，如果不还原，对应加密又是怎么处理的
> 你这个说了不是和没说一样。。。这个重点是四个未知的值异或，无法从中分离出原来的值。就像四碗不同颜色的水混一起了，水当然在，问题是颜色怎么分出来。

例如四个有效 byte 分别为 0x11 0x22 0x33 0x44 ，那么 0x00000011 ^ 0x00002200 ^ 0x00330000 ^ 0x44000000 丢失它们了吗？ 0xabcd0011 ^ 0xabcd2200 ^ 0x0033abcd ^ 0x4400abcd 丢失了吗？如果你认同这个例子，那你再看一遍 @hcocoa 说的。

我坚持 #2 的观点，一通分析，最后代码多半还是得这么写。。。如果你真的对这种挑战感兴趣，可以看最后一个链接，至少去掉编译器、代码混淆、反汇编反编译的影响，可以直接分析源码。

- https://eprint.iacr.org/2013/523
- https://crypto.stackexchange.com/search?q=white-box
- https://segmentfault.com/a/1190000041023774/en
- https://developer.apple.com/streaming/fps/
- https://whibox.io/

而且你看你发的这个链接里的注释...
// This looks right to me, at least for decrypt_kernel
// round is 0..8?
// This COULD just be Rijndael key expansion, but with a different set of S-boxes
// This MIGHT just be AES, or some variant thereof.

这种项目都是逆向得来的，可能是从高度混淆的程序的反编译结果中摸索提取出来的，可能是常见算法的一个变种，可能是白盒加密，我觉得实在没有必要搞清楚它是什么。

没试用，只能说出两点肉眼可见的无法取代：移动端，打磨这个应该很费精力； E2EE 承诺，这个我在文档里只找到一句"用 UDP 建立和使用对等连接过程中,也存在特定格式的消息,这些消息全程加密"，这很没有什么说服力，毕竟这个项目不像同行依赖于成熟的 wireguard(-go)，并且我认为这个特性是很难在后期新增的，而对我来说组网工具是很需要建立信任的东西。

别的很多都是可以慢慢堆上去的特性细节就不提了。

我能看到的亮点是加入了混淆，但这只是我作为墙内用户的一种偏好，它实际上是否合理还需要让专业的人评价一下。

以上只是我浏览几分钟后的想法。

@0o0O0o0O0o #2 https://go.dev/play/p/QXtXR24OeCO