@dyxsdtc 感谢您的回复 :-)

关于缩写，在完整文章里 UTM 和 PRG 在第一次出现的时候都是 abbr 元素，并且有加点线提示，光标移动上去可以看到 tooltip ；并且在打印的时候会转换为 Abbreviation (full text) 的模式。既然 UTM 有了，就懒得写 TM 了。

在翻译之后的版本里我就偷懒了 >_<

并不算是疑问吧，因为我写的时候已经意识到了我之前的想法是不对的，后面的解释确实是这样。And you're right, 我几乎忘记 keygen 也是（或者也可以是）算法的一部分（因为我学的对称加密里面通常 key 就是直接从一个集合的均匀分布里面抽取，所以不需要 keygen ）……感谢提醒。

我个人不做破译密码（ cryptanalysis ）的工作，所以没关心过 attacker 怎么操作的问题；我所学的是各种密码学对象的“语法”定义和安全性定义、知名的密码学对象构造方法以及密码学命题的论证技巧等，顺带了解一些实用算法（的简化版本）。

与其说“暗含”，我更愿意说是“自然地包括”，而且这种用法是数学中 idiomatic 用法：这种现象在计算理论或者微积分里面都有，定义里量词的顺序是表达了含义的。

<code>`</code>

或者 `` ` ``，行内代码前后必须有相同数量的 ` 才被关闭，当然这里会多出来空格。

另一个解决方法是改写编译器，我目前就是这样做的，例如

``code:`:`` 会被编译成 <code>`</code>

`math:x^2+y^2=z^2` 会被编译成 KaTeX 公式

@wevsty 最开始有 GC，所以假定不是自己管理内存 - - 如果是 C/C++ 那就没这个问题了，毕竟可以自己控制。

@Tunar ？（亚洲人问号）这篇文章和大素数的关系是啥？

@wevsty String 是不可变，且 String 是 final，因此这条路走不通。

而且一个程序不可以依赖 finaliser 来做清理，因为在内存足够的硬件上，GC 可以选择永远不回收内存。

@fucker

> 回复语气太正式

实际上是因为表述方式太形式化（“下面四个命题有一个是真的”是经典成语 TFAE 的变体）

> 冒犯

并不算是冒犯，但是一个我觉得不礼貌的行为不是非要引起别人的不适。第一次见这个的人当然没有恶意，我只是对这个感觉 fed up。

> 挺伤人的一个词

取决于用法，这个词（在普通话里）似乎本身还没有太明显的感情色彩

> 区别巨大

主要原因是第一个音节的复印是很不同的（英语 dʒ、汉语拼音 j 和粤语拼音 k 的区别真的很明显），第二个音节的元音的区别也很大

> 例子

这两个例子中，两个语言中发音的差别都很大，因为一个语言里可以存在另一个语言里面没有的音。

> 挑刺

因为我的书写是追求准确的 - - 这并不是玩笑。

@nevin47 你的想法有很多值得二次思考的地方……比如为什么再次加密后破解难度指数增加？用于二次加密的密码存放在哪里？如果也在进程内存，只要读出二次加密的密码再解密私钥密文不就行了？

@geelaw 果然写错了，二分查找的部分应该是 inputArray。另外实际上可以用 sparse array 来做这件事情，不需要二分查找。

@ech0x 不能，只要你的程序能做的，能控制你的程序的程序都能做。

/* in-place, destructive */
function treefy(inputArray)
{
var outputArray = [];
inputArray.forEach(function (comment) { comment.comments = []; });
inputArray.sort(function (a, b) { return a.commentID - b.commentID; });
var helper = function (begin, end, n)
{
if (begin >= end) return null;
var mid = (begin + end) >> 1;
var testee = outputArray[mid].commentID;
return testee < n ? helper(begin, mid, n) : testee > n ? helper(mid + 1, end, n) : outputArray[mid];
};
inputArray.forEach(function (comment)
{
if (comment.comment_parentID == 0) outputArray.push(comment);
else helper(0, inputArray.length, comment.comment_parentID).comments.push(comment);
});
return outputArray;
}

没有测试过, provided as-is.

实际上可以直接用 Process Explorer 查看进程里面长得像字符串的东西，这也是可能看到密码的。


@ech0x 但是 char[] 是可变的，因此你可以用完之后手动填充为空白。这样做是为了保证用完之后内存里不再有这个串。

然而很糟糕的是，对于复制 GC 这一招还是会被攻击。


@nevin47 如果没有解密私钥的密码怎么解密私钥……？而且要用的时候仍然需要把私钥解密。

正确的实现是，如果标题以任何语言的“回复”“转发”加上冒号开始，则先去掉，看作标题，然后加上当前语言的“回复”“转发”和冒号。

在回复邮件的时候带上全文是正确的，一些客户端具有“打开对话中一条消息”的功能，如果你不加上全文就会导致读对话很麻烦；一个聪明的移动客户端也会在阅读对话的时候自动隐藏引用内容（对于桌面客户端，没这个必要，因为一个对话里面的邮件不是摞在一起的，而是左边有个列表让你选）。

@tony1016

Euh... 深入浅出 和 太深 似乎不矛盾 - - 原文末我有一个简单的总结的：

> 所有在开始使用算法之前固定的东西都应该当成并且需要公开。

另外这篇文章并不深，这个内容应该是二年级的感悟，我都快四年级了。

@SuperMild 那你没有理解我想表达的——因为从样子上看你可以把“算法”写进“密钥”，比如我提到用 UTM，密钥是两对算法，这样这句话就不直觉成立了。

这篇文章的主要目的是解决什么属于这个语境里面的“算法”（需要保密的东西）。

@momocraft
@fucker

下面四个命题有一个是真的：

- 英语发音错误；
- 汉语发音错误；
- 没有把域名用英语读；
- 说的不是普通话或者粤语。

Gee Law，普通话的“基佬”和粤语的“基佬”的发音都有巨大区别，不可能弄错。

英语 Gee Law /dʒiː lɔː/

普通话 基佬 /tɕi1 lɑʊ̯3/

粤语 基佬 /keɪ̯1 lɤʊ̯2/


对别人的名字品头论足是一件很不礼貌的事情；即使最初我觉得这个解释很有趣，我也会觉得厌倦——这个梗已经存在至少 7 年了。

@bp0

这个方法的可移植性 和 程序的可移植性 没什么关系，因为这个玩意儿是给 **调试** 用的。正常使用（而不是调试程序）的时候不会应用这个策略。

这里的“让它 crash ”是在调试阶段暴露问题，在生产阶段，因为一些优化的考虑，不可能做这么多防御措施。

如果你在书写可移植的代码，那么你可以在一个有这个调试功能的平台上完成调试之后到其他平台用。


@VYSE

（所以 0xdeadbeef 不能 mmap ？我不用 *nix 不太懂。）


@VYSE
@wind3110991

如果有两个指针指向同一个动态分配地址，那么仅仅设置一个指针为 nullptr 或者一个特殊的数是没有用的。

这种情况或许容易检测，但是更困难的是，你分配了一个数组，两个指针一个指向数组开头，一个指向数组里的另一个位置，然后你 free 数组开头并重置指针——这样虽然后一个指针并不等于被释放的指针，仍然变得无效。

@bp0 因为在这个模式下，如果你释放内存，整个 page 都会变得 invalid，就好像这个 page 从没用到过一样（但是 heap manager 会避免过早再次使用这个 page ）。

举个例子，第一次分配 1 Kb，记在 p 里面，第二次又分配 1 Kb，记在 q 里面，假设第二次分配的那 1 Kb 在第一次后面那一个 page。

做这个：free(q); printf("%c\n", *q);
相当于：free(q); printf("%c\n", *(p + PageSize));

把 q 释放之后访问 q，是访问无效的 page，这里效果上等于 p buffer overrun，是会被检查到的。

至于一个 page 具体是怎么被 decomitted 的，这我并不关心。

**此外，free 掉一个指针之后设置为 nullptr，不代表原来其他指向它（或者这个数组其他位置）的指针也变成了 nullptr。**

如果你可以把所有和这块内存关联的指针都找到并设置为 nullptr，那恐怕是可以的——但是这样的入侵性很强，还有可能让你不知道什么时候一个指针就被篡改了。

至于一个 malloc 的实现可以抵抗双重释放，不代表书写双重释放的代码是可以接受的——这样的代码不可移植，而且在地址被重新利用的时候会引发更加糟糕的错误。彻底解决的方法是杜绝程序有逻辑问题，而不是掩盖这个问题。

扩展阅读
https://stackoverflow.com/questions/1879550/should-one-really-set-pointers-to-null-after-freeing-them
https://stackoverflow.com/questions/1025589/setting-variable-to-null-after-free

@tyfulcrum 取决于逻辑，不能一概而论，所以我说“任何情况（也就是不考虑具体情况）都在 free 之后立刻设置为 nullptr ”是不好的。