@Kauruus #5 结论是对的，但论证有些问题。密钥错误的时候以压倒性的（ overwhelming ）概率报错，但不能排除解出乱七八糟结果而没有报错的情况，遍历所有密钥的时候遇到不报错的错误密钥的概率可能很高。解决方法就是多试几次。

另外楼主的问题里面，“加密两次”的含义不明确，因为基于 AES 的加密通常不需要隐藏 IV ，外层加密的时候内层 IV 设置为明文还是关联数据，会导致不同的攻击方法。攻击多层加密的一般方法是所谓的 meet in the middle ，尤其对于加密随机数公开的对称加密（常见的基于 AES 的加密，加密随机数就是 IV ，是公开的）。

One-time password 就是 MAC （消息认证码）的一种应用，如果用 HMAC ，那么根据 https://cseweb.ucsd.edu/~mihir/papers/kmd5.pdf 破解的方法是破解底层散列函数的抗碰撞性或者用作 MAC 时的特称不可伪造性（ existential unforgeability, EUF ）。通常认为使用的散列函数满足这两个性质，因此在模型内无法破解（当然，知道 HMAC 密钥自然就破解了）。

@NoOneNoBody #3 “破解”一词的三重理解：

1. 一种无法言说的意思
2. 及物动词，必须搭配一个宾语，且宾语必须是某个安全性质的名字
3. 及物动词，宾语可以是安全性质的名字或者密码学对象的名字，如果是后者，则意思等同于 宾语 = 此密码学对象所属类型的最常见的安全性质

通常来说，散列函数最常见的安全性质是指抗碰撞性，因此“破解散列函数”的意思就是“能够较高效地找到散列函数的碰撞”，所谓“逆向搜索”一般来说理解为计算原像，即破解单向性，破解单向性蕴涵着破解抗碰撞性，因此“没能破哈希”对于某些散列函数是错误的说法。

当然，我们回到 1 的理解，可以 psychic debug 你的意思是说没有听过能破解散列函数构造的 HMAC 的安全性，这对于一些散列函数也是不对的，比如 MD5 的抗碰撞性质已经破解（允许选择前缀攻击），因此单纯用 MD5 制造的 HMAC 不安全。

当然，one-time password 使用 MAC 的方式表明即使破解了 EUF 也不代表就能破解 one-time password ，因为 one-time password 里面被认证的消息是时间戳，并不允许使坏者（ adversary ）任意选择。

@geelaw #26 ugh 税是

(cPrice * bpTaxRate - 1) / 10000 + 1

脑子糊了

@drymonfidelia #20 正确的做法是金额存成 cPrice = 10000 美分，税计算为 ((cPrice * 10000 * bpTaxRate - 1) / 10000 + 1) 美分，其中 bpTaxRate 是税率的基点数（万分之几）。这里假设 cPrice 是非负数（销售），处理退款更麻烦。

@geelaw #1 眼拙我，应该是

Dart < Go
Go > Forward
Forward = Forward

通常来说 a.compareTo(b) < 0 用 a < b 表示，脑内模型应该是对于实数 a, b 有 a.compareTo(b) 和 (a - b) 的符号一样。

所以应该写 Dart < Go < Forward = Forward 。

请看 /t/519617 里面我的回复。

@kera0a #3 @NessajCN #7 #11 #15 #18 #20 @amiwrong123 #10 #19 #30 @LaTero #13
@iOCZS #26 @R18 #36

“用私钥加密，用公钥解密”在任何一本密码学教材上都不会出现。此外，私钥加密蕴涵着数字签名（这是一个公钥对象），但目前不知道数字签名蕴涵着公钥加密。

另请参阅 https://www.zhihu.com/question/432504839/answer/1681747812 答案和评论区。

如果你是在 Windows 的“属性”对话框里看到的 Image ID ，那么它可能对应的是 ImageUniqueID ，用

exittool "-ImageUniqueID=" C:\path\to\file.jpg

可以删除之。

@hesongtao #7 典型的 UWP 都是自己绘制非客户区的（应该是 XAML 框架或者 CoreApplicationView 做的），所以都受到此问题的影响。

@hesongtao #8 沿着其他路径拖动会先让窗口还原，所以 Fitts 定律的 hack 不会出现。这些问题的根源似乎都是 Aero Snap 没有让窗口先恢复为还原的状态。

@hesongtao #3 看到图了，看起来是 Windows 对最大化窗口的非客户区有新的处理，可以看出那个白条实际上是额外的非客户区（注意最小化等按钮）。

同时我觉得我的猜想应该是对的，窗口的系统绘制非客户区和自己的非客户区都显示“向下还原”按钮，虽然目前窗口已经不是最大化的状态，这说明窗口（受 Aero Snap 影响）错误地以为自己依然是最大化状态。

可以猜一个临时解决方案：再次执行 Snap ，例如用鼠标或者 Windows + 方向，应该可以缓解此问题。

截图看看？

另外 Word 和 Chrome 都是自己绘制非客户区的，可以试试 Explorer 的窗口（系统绘制非客户区）是否有这个问题。当然，如果同一个软件旧版 Windows 无此问题的话，这依然是 bug 。

非客户区：标题栏和调整尺寸的边界和最小化、还原、最大化、关闭按钮。

我的猜测是这样的：最大化的窗口实际上会溢出屏幕几个像素，是古代简便实现 Fitts 定律的方法，在 Aero Snap 里用楼主的方法操作的时候，窗口一直保持最大化而没有向下还原，而进入 1/4 布局（预览？）的时候窗口依然没有向下还原，只是改变了最大化的尺寸，自己绘制非客户区的窗口依然绘制溢出屏幕的像素，也就是白条。

Windows 最近有很多 Aero Snap 的 bug ，我目前用的版本依然有从最大化按 Windows+左右 一次，Snap 的窗口尺寸错误的问题。

技术上正确的说法：不会。因为数字签名不一定伴随抗碰撞散列函数。

实现上准确的说法：Windows 现在使用的数字签名的验证方式的第一步就是计算文件内容（如果是内嵌签名，则删去内置签名部分）的某个散列函数，再继续验证步骤。所以验证签名本身就“验证了散列值”。

如果系统启用了驱动签名校验，且签名后的驱动被修改为不同的文件，且被修改过的驱动没有重新签名，且没有攻破签名方案，那么 Windows 会拒绝加载修改后的那个驱动。

@dilidilid #1 无提示通话录音在美国不违法，联邦法律只要求至少一个参与对话的人允许录音，既然机主和其他人打电话，机主自然可以允许自己录音，而不需要提示其他人。

注意：有些州有更严格的规定，比如 Apple 总部所在的加州规定所有参与对话的人都要同意才可以录音。

几乎不可能，现代英语的读音和拼写的关系很混乱，要确定正确读法最好就是查字典。

用函数作用于一个输入，那么输出是固定的，没有任何随机性。如果输入本身是随机的，那么作用函数之后依然是随机的，但熵不会增加，而且非常明显的例子是把具有 1024 bits 熵的输入用楼主提出的两种方式作用，得到的结果熵必然不能超过 256 bits 。

当然，经过函数作用后，“计算熵”可以增加，然而标准模型下很难分析 SHA-512 和 SHA-256 对输入的计算熵产生何种影响。

只考虑抗碰撞的话，多个函数复合的抗碰撞能力当然不超过最里面的那个的。

@HFX3389 #3 这个说法听起来很倒反天罡，因为“券”是正字，要说通假也应该是“卷”通“券”才对。

查阅《汉典》，两者无通假关系。纯粹是打错字。

可能是《大长今》里冒出来的

另外 ModifiableWindowsApps 的用途似乎是 https://superuser.com/questions/1519173/what-is-the-modifiablewindowsapps-folder-and-can-i-delete-it