我不得不说...

我自己就是 Manjaro+KDE 。用了好多年了。一个有 1050N 卡的笔记本。
第一天的时候刚装 Manjaro 直接不能开机. 最后要改内核引导参数。和 ACPI ，N 卡什么毛病有关。
而后想双显卡，经常出问题。卡顿，画面撕裂。后来直接全部 GPU 渲染，
不记得后面又有什么问题了，反正一番折腾再接下来就累了，直接 mhwd 默认 video-hybrid-intel-nvidia-prime 了。
但是默认配置也一直有问题。什么问题呢？

1. KDEconnect 或者什么东西弹出提示后有概率 KDE 卡死。弹窗不消失，工具栏，菜单无响应。
2. Alt+Tab 后界面直接卡死，卡到崩溃，等待几秒中然后 plasma 自己会重启。
3. 任何 CPU 渲染的界面都低帧率。弹个开始菜单卡成 PPT 。

这些问题困扰了我两年，甚至有时候弹窗卡住我就按 Alt+Tab 同时触发 Bug1 和 2 直接卡死让 plasma 快捷重启。试着解决无数遍，一直没啥效果...

直到今天，
楼主你发了这个帖子，我为了看看你说的 kvantum 全面升级了一下系统。
然后上面这个困扰我两年的问题莫名其妙的好了，但是 Chrome 莫名其妙卡得很，打开硬件加速就好了，跑起来一点问题没有。之前不开硬件加速是因为开硬件加速 Chrome 会崩溃....

额，谢谢楼主！...

顺便一说，我觉得 Manjaro KDE 默认的配置稍稍调调也很不错啊。

不好意思，没仔细审题，一次一密码，给上上下下都道个歉，想删除的时候不小心发出来了。尤其是给 @Citrus 道个歉，我没仔细审题。
你提醒我了，你说的对。送一个感谢表示诚意。

感觉怪怪的，想了一会，没想出有啥问题。

不安全，某些情况请千万不要这么做。你的理解大致是正确的，但是尽可能不要固定 IV 。

赞同 @liuidetmks

AES 归 AES ，但是你的加密模式是什么？楼主没有说。
比如，在上面说的 OFB 和 CTR 模式等等情况下，IV 重用并且密码重用的情况下基本就完蛋了。
比如 CTR ，你只需要知道你的明文去和密文 XOR 一下你就知道密码流了。未来的加密形同虚设。
在 CBC 模式虽然不会被直接破解，但是密文相同，破坏了语义安全。有些场景可以接受。

我简单介绍一下一些概念吧，完美安全和语义安全。
完美安全性就是密文本身不会透露任何明文信息。这个太难了。根据信息论，你需要随机密钥+密钥长度至少有明文那么长才能做到。这个时候你的熵就高的足以用来混淆任何一个明文 bit 。
所以楼上 @Citrus 其实说的不完全正确。因为你密码长度只要小了就是不行。不是说会暴力破解，单纯就是熵不够。
你说的严格一次一密，你是指每个 block 都一密码还是完全参照已有的 AES 模式呢？如果你能做到前者，恭喜你，但是直接换成 XOR 玩 OTP 可能更好。做到后者，比如 CBC 模式中，密码随机 IV 固定依旧做不到语义安全。
做到这个太难了。密钥生成，传输，都是问题。

于是人们退而求其次，密文可能会暴露明文信息，但无法被有效利用。这个就是语义安全了。
保存和更新密码的成本太高了。默认密码就会重用。设计的时候也是这么设计的。

这个时候引入 IV 你的确可以理解为增加信息熵，增加密文随机性。某种意义上来说 IV 解决了密码重用的问题(密码学角度的问题)

@raw0xff 你没搞明白的是谁在防谁。
这个机制不是让你服务器防着恶意客户，而是让正常客户防第三方网站的攻击。防止第三方攻击者在正常客户的浏览器中模拟正常请求访问你的接口。这个是在保护浏览器安全，不是保护服务器安全。

你的客户可能在第三方网站被钓鱼，假设没有同源策略，假设你是银行，此时恶意的第三方网站里有个脚本会在用户浏览器里运行：自动模拟你网站的转账操作，发给你的接口。由于没有同源策略，这个请求因为带着你客户的 cookie 等信息。你的客户就这样莫名其妙被偷了钱。

或者你是一个 webmail 但是人家也可以通过类似手段，在三方钓鱼网站里插脚本控制用户浏览器，进而偷到你客户的邮件。

你说请求在接口处理与否取决于你的代码，但是这个伪造的请求千真万确是客户端浏览器发的。看似完全正常的请求，正常的 Cookie ，同样的 IP 。Referer 头不靠谱而且可能被绕过，你说用 Token 但是 Token 也可能被偷(如果没有同源策略)。你服务器要怎么检查？？

因为这种攻击发生在客户端，所以客户的浏览器实现防御才比较容易。
于是有了同源策略 SOP ，注意，SOP 不阻止请求发出，但是可以阻止带着 Cookie 。还有非同源页面能否读网站响应。

你会发现请求不带 Cookie, 同时脚本不能跨源读数据，
上面说的两种攻击基本上就被阻断了。（当然实际情况更复杂些）
但是前后端分离也同样被阻断了。


你说的：
> "浏览器访问 a 网站时 a 网站的脚本访问 b 网站，无论是 post get 还是 options ，是否响应是 b 网站自身逻辑说的算的，即便 Access-Control-Allow-Origin:* 也只是告诉浏览器 b 允许所有来源访问，至于如何响应是看代码。"


带上 SOP 以后，由 a 发起的访问 b 网站的请求不会带有 b 的 cookie ，响应也未必能被 a 的页面读取。敏感操作和敏感信息都 a 都搞不了。

而 Access-Control-Allow-Origin 是 CORS 的一部分，作为同源策略 SOP 的扩展，允许你提供接口的服务器指定哪个网站可信(可以发 cookie 和可以读响应)，就是告诉浏览器第三方网站的白名单，白名单里的网站应该不会让浏览器发恶意请求，可以让 SOP 信任。CORS 给开发部署提供一些灵活性。这样你又可以前后端分离了。

顺便，你设置成 Access-Control-Allow-Origin:*的时候，浏览器的 Cookie 是不会发出去的。这整套机制都是怕浏览器被第三方恶意网站利用。
至于调试工具，，你不用调试工具当日常浏览器，不用担心被钓鱼，而且 CORS 也要被调试。所以当然不遵守这些。

楼上有人说的 CSS 应该是 XSS. 那个是 CSP 机制的事情。因为恶意脚本插入正常网站后是同源的。

楼主感到疑惑：貌似只是告诉客户端一个白名单让客户端自觉连接，服务端是不是还要判断 @$%^&%
楼主可能知道这是什么，但是不知道这个目的是什么...我们从头来说吧

5 楼说了安全问题。是的。如果 A 网站能读取浏览器保存的 B 网站的 Cookie ，或者 A 网站的脚本能随意让浏览器对 B 网站发起请求(比如转账操作)，是不是不安全？

于是搞了一个同源策略。如果非同源，即便要求发 Ajax 也会拒绝。非同源就 0 信任。
但是这样的同源策略是否有些过于严格？

如果我前后端分离，我域名或者端口就是不一样怎么办？我前端就是需要加载别的域名的 API 怎么办？反正我就是要加载非同源的东西，你一个同源策略因为安全问题就把它堵死了？搞得 AJAX 用不了。

楼主说的 Access-Control-Allow-Origin 这就来了。
后端需要告诉浏览器，哪个前端网站你可以信任，在他的页面可以给我发请求，我们是一家的。

这是设置一种因为信任而可以设置安全例外的做法。

客户端不自觉？那是客户端有安全缺陷。你做网站的恐怕做不了太多。

@cmdOptionKana 我赞同你的说法。
我也认为，如果特别“厌蠢”，可能缺乏耐心和换位思考能力，对结果焦虑或者有别的心理/情绪障碍。
但是也正常，谈不上心理障碍。

但是我个人认为不是逆反心理。可能你在当时感到焦虑在大脑里留下负面印象后，你父亲问你的时候你会开始 panic
尤其是渴望得到父母肯定的阶段，小孩会因为自己的行为而感到懊恼，或者因为父母的批评/压迫感而焦虑。
这种焦虑多次出现以后就会建立一个非常负面的正反馈。
以后会在每次遇到同样的事情时，焦虑发作，开始占用很多意识资源，思考不了。
在家长看来，一提这个问题怎么这倒霉孩子就和我急？这是和我“对着干”？逆反？


另外，说说 教人教不会
就像很多老年人不会用电子产品，因为他们对这东西没兴趣。很多年轻人觉得理所当然的 UI 设计他们也看不懂。
我举个例子

比如德语，krankenversicherung ，法语，intergouvernementalisations
对于母语者记忆这些词是比较轻松的。但是如果你不是，而且你没有基础，无论教还是学，都很痛苦。

换个更容易理解的角度说，
比如“沐浴”的“沐”，
我相信在这里的中文母语者应该都在学了“什么是三点水”，“木”这两个东西以后再接触这个字的。你很容易学会这个字的读写含义。
但是，你找个分不清中文日文的外国人，你让他学，他会很痛苦。
在他眼里只是觉得这是一堆点和线堆砌的复杂恶心的结构(还有笔划顺序)，还要记怎么读，什么读音，什么意思.....


同样我也想这里吐槽我的某些老师，他们支持“你学习时间越长越好”“你背下来就行”
这些老师很努力，很痛苦，很愤怒，很困惑。“这孩子是不是蠢...？”
其实你也很努力，很痛苦，很愤怒，很困惑。“我是不是真蠢......”

不是所有人都有一样的“基础知识”

回到这个主题，我不认为这是心理障碍。每个人都在用自己的视角看问题，很正常。
但是你也的确应该用别人的视角看一下，看一下别人知道什么，这坑多深得填。
如果你觉得教的成本过高且没收益，就算了。不生气。

简而言之：
Charles 篡改了通信内容，普通代理没有。
Charles 为了能抓包看明文，要破坏了加密，伪造证书搞中间人攻击。但是普通代理没在乎，看啥转啥。


不简而言之，说个场景：


A 和 B 要写信，这信都在盒子里送走，这盒子最好要上个锁，防着邮差。

于是 A 和 B 决定：

1. 正常通讯都用密码锁，安全还方便。
2. 所以，通讯之前，A 要把 密码锁的密码 发给 B 。然后他们就可以用密码锁和这个密码通信了。

问题是，这个送 密码锁的密码 的盒子，本身又该怎么确保安全？
3.于是，B 只能先把自己的，经过 ”权威机构认证的 B 专用锁” (B 的证书) 发过去，这锁的钥匙只有 B 他自己有。
4. 然后 A 收到后，就用 B 的锁，锁住里面是密码的盒子，发给 B 。
4. B 就可以用自己私人钥匙打开盒子，看到密码，接下来就可以也用 密码锁 锁住盒子来进行接下来的安全通信了。

Charles 和普通代理都是送盒子的邮差，但是有区别：
Charles 为了破坏加密，会在中途，把最开始 B 的锁换成自己配的锁，而自己则收下 B 的锁。这样，A 会用 Charles 的锁来锁盒子。A 想出的密码这下邮差 Charles 就能知道了。Charles 也可以假装 A 给 B 发一个自己编的密码。

Charles 可以对通信为所欲为，这样加密就完全被破坏了！

然而 A 发现 Charles 调包过的锁觉得不对劲，这锁也没经过权威机构认证啊，看起来绝对不是 B 的，我不接受！于是他停止了发信 (报个错)，B 也迟迟没收到来信所以这事情就没了下文。

(以上是过度简化且不准确的 TLS-RSA ，就不提 dhe 系列了。反正证书被换了就不该有下文。)


而普通代理该送啥就送啥。根本懒得看里面是啥，也压根没碰过。
管你是 https 还是 DNS ，还是什么锁，反正有东西我都送走就是了。

这里最大的区别就是：Charles 篡改了通信内容破坏加密，但是普通代理没有。


最后，你可以 root 后导入你 Charles 的证书到系统证书里。运气不好的话你可能遇到了 SSL Pin. 我之前用 Xposed 模块解决的这个问题。

1. 貌似天文那边抱怨过光学污染这事。
2. starlink 的确之前有和欧洲卫星和天宫潜在碰撞风险的事情。但是低轨道卫星报废后会坠毁进入大气层烧毁不会一直转圈。
3. 至于卫星相撞历史上发生过。的确要计算规避。
4. 碰撞概率并不是那么简单计算空间大小然后平均分布的...starlink 占用的低轨道基本都是一个半小时绕地球一圈。和它轨道交错的卫星又不是没有。这么一圈一圈几年下来难免会有碰撞可能。
上面有人说 6600 辆车才有多大空间，可是目前低轨道卫星有将近一万颗。

想一想，一万辆 1.5 小时不到就绕地球一圈的车，不少还路线互相交错。一年将近六千圈，每圈又和一些别的轨道交错。这五年十年下来难免...

有价值的轨道是有限的。starlink 这些年已经在越来越频繁变轨规避碰撞了，过去六个月进行了 5w 次规避机动。
顺便，根据各种发射计划，目前在轨卫星还远不算多。

另外说点轨道污染的问题。这么说吧：
Kessler syndrome: 在某个临界情况，比如可能会因为一次卫星碰撞产生上千个碎片，这些碎片可能击毁别的卫星而产生更多碎片，最终可能会是链式反应...

另外说回到楼主说的 DF31AG ，我不了解。猜测算过，不然麻烦比较大。另外如果 ICBM 被通讯卫星拦截这是否...

我还从来没在最近 A 股有关帖子下评论过。我知道这样评论得罪人：

我觉得有部分 V 友投资心态真的不怎么好

作为会深夜和哥们出去喝酒的，我打个比方
像面对渣男渣女：
“虽然 ta 虐我千百遍，但 ta 这次，肯定还是爱我的！”
“虽然 ta 虐我千百遍，但是你说 ta 会以后会不会一直爱我呢？”
“虽然 ta 虐我千百遍，说不定我还有机会！”

楼主来迟了，看着上面的内容，叹道：

“虽是渣女，但是她现在正在和别人在宾馆里，而我却只能看着。”

唉，投资理性一点。

有区别。而且，使用 SHA1 就是在往枪口上撞。
MD5 和 SHA1 都存在比较容易利用的长度扩展攻击。楼上已经讲过。
就是你知道 h(a)和 b ，但是不知道 a 是什么。这种情况下你依旧可以直接用 h(a)和 b 构造出 h(a+b)。
这些会有长度扩展攻击的 hash 算法你可以理解为，在计算时是一块一块处理的，会把之前一块 hash 结果拿过来带到下一轮用才这样。

所以
如果你是 sha1(key+msg)的话，你可以不理会 key ，随意在 msg 末尾加 msg2 得到 sha1(key+msg+msg2)。
就像黑绝改宇智波家族石碑一样。

你说，那我反过来，我把 key 放后面呢？

那攻击者需要构造一个 msg2 能碰撞 msg 。sha1(msg2)=sha1(msg)
服务器那边 sha1(msg2+key)计算出来的结果应该和 sha1(msg+key)一样。

当然也有人干脆 sha1(key+msg+key)。据说也不好。我没研究过了。

HMAC 就是为了应对 MAC 时避免 hash 算法缺陷的东西。
所以用 HMAC 吧。

看着不错，这名字一看就挺 diao 的。
但是网址呢？

这个几乎是肯定的。我在好几年之前也听人说过这种问题。
另外用加密消息用 QQ 微信之类的一段时间，听说也有人被封。(未确认)

OP 有空可以试试控制几个变量：
1. 文件头
2. 后缀(和文件头配合或不配合)
3. 文件名

我觉得百度网盘应该会为了节约算力/时间会只检查文件头。比如你存成.zip 加上 PK 文件头，只要文件够大，他们应该不至于一个个解压。
所以 OP 可以试试，加上文件头和对应后缀后说不定可以逃过？
我没有百度网盘不方便自己测试就是。
如果楼主有兴趣的话。

挂后台听反而要求比较高。
强烈推荐 天豪公开课。偏学院派的历史主题，偶尔擦边时政。大多数时候不需要看屏幕，听就好。
英语可以的话，kurzgesagt 这些。但是缺了画面不太行。
对生物感兴趣可以听 芳斯塔芙(感觉是 B 站搬运/偷过来的)

其他基本上不看视频就听不下去。

老高经常胡扯...虽然说故事类的你听着乐就行了，但是如果讲的东西你了解，他说的又是错的，你会听着难受。

你这个需求可能更需要播客或者听书之类的。