• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2744 days ago, the information mentioned may be changed or developed.
 |
101
NotFamous Dec 3, 2018
翻页
|
 |
102
SsuchingYu Dec 3, 2018 via Android
一则笑话引发了关于 Base64 的大论战。
|
 |
103
epicnoob Dec 3, 2018
杠精真多啊，非得纠结一个概念的事情。
|
|
104
epicnoob Dec 3, 2018
https://www.dictionary.com/browse/encryption
encrypt 跟 encode 就是同义词 |
 |
105
stebest Dec 3, 2018
妹子在讲段子吧
@binux 一个比较简单的区别-- 编码：内容可以根据约定的算法，在不同的格式间独立转换，也就是转换过程不需要借助额外的内容 加密： 同样是一种格式转换，但转换的过程中就需要额外内容，也就是加密密钥。对应的，解密的时候也会需要解密密钥。 通常加密要比编码的要求严格得多，当然，非要抠字眼的话，照你的“严格来说”（不应该是特俗情况下？），加密和编码就没有区别了，毕竟在任何特俗情况下，比如对方不懂你的编码方式，那就算作加密。安全系统的设计也就没啥意义了。 |
 |
106
xxdd Dec 3, 2018
我怎么感觉这是个很棒的营销啊
学习了~ |
 |
107
tabris17 Dec 3, 2018
楼主把加密技术卖给这家公司，要走上人生巅峰了
|
 |
110
ukipoi Dec 3, 2018
2 进制和 10 进制的转换，算加密么？
2 进制和 10 进制转换之后，10 进制的数据 0 代表 9 9 代表 0，算加密吗？ |
 |
111
FrankHB Dec 3, 2018
@binux 所以说了，你得加入一大坨*独立于*编码手段的对不同涉众有特异性的假设，才能让一种并没有密钥设计的编码系统用起来显得像是起到了加密的作用。一旦这种假设不存在，任意公开了编码表的 Base64 和 Base64 变体这样的具体编码方法都没法实现隐藏密文无法被任意解读的目的。英文维基中 encryption 的解释中，in such a way that only authorized parties can access it and those who are not authorized cannot 明确指出了实现这个目的应有的性质：保密性。
上面是我一直重申的关键理由，也是你想象中的定义（中文维基定义）少掉的解释不清楚的部分。 就你的例子也可以说明一些问题：印第安语之所以能实际地作为“加密”手段，就是因为你可以预期只有特定的授权方——接触密文并且懂印第安语的——才能解读密文，这是一种和印第安语自身无关但比较容易实现的假设。而换用 Base64，你如何实现这个性质？除非有人肉 Base64 解码大师并且这正好是你需要授权访问的对象，Base64 的“密文”一眼看过去*对谁来讲都是同等不可读的*，何况（上面 @no1xsyzy 提到过）这种文本表示的 Base64 的编码特征实在太明显了，不靠谱到对不特定访问者来讲几乎都能一看就知道解码有戏，甚至立刻猜出来需要尝试的解码方式；把成功解码 Base64 视为解密，比翻译自然语言还简单，怎么看都不够格跟印第安语比嘛。 关于置换编码表的变体，确实存在一些方案，但是比起任意的置换编码表来讲显然是极少数。这些变体编码方案叫 Base64 是因为和原始的设计有历史渊源，而不是因为编码表指定了多少编码索引。或者说，和你理解的不同，符号表还就是 Base64 的一个部分，只不过不同变体可能稍微调整而有不止一个；但也仅仅“不止一个”，*不是随便你改完以后还能叫做 Base64*。不限制编码表具体编码的这种编码结果，*可以称为 radix-64 表示，但不太可能恰好是 Base64*；任何你找得到叫做 Base64 编码的总和也只是其中的一个很小的公开的真子集。因此如果明确保证用 Base64，所有这些变体也太弱了——暴力遍历这些公开的编码方案中的解码操作即可破解。由于已知密钥的授权方解码 Base64 本身已需要解码开销，授权方和未授权方所需要的计算开销基本上只差一个小的常数（ Base64 方案数），实际上没法靠解码成功区分授权方和未授权方，因此保密性不存在。 （其实就魔改加密的目的上说，因为 US-ASCII 是 7-bit 编码，octet 要凑成 8-bit，input padding 这里搞不好花样还能加不少……但非对称加密和 PKI 到处都能用的场景下为啥要自己搞这种吃力不讨好的事呢。） 至于 RSA 算法，前提就要求选取的质数不能都公开了（否则分分钟算出私钥），自然也不能是小到随便能猜到的……非要说小质数的前提下算不算能实现加密，那么确实不算。但这和说 RSA 有效地实现加密是两回事，后者指 RSA-n （ n 可以任意地长）不能在合理资源内成功攻击；如果 n 足够小，你的确可以说这样的 RSA-n 没有资格称为加密算法。只不过就密码学目的来讲，对不确定的 n 分析，犯不着单独算成特例排除而已。 @epicnoob 是同义词又不是等义词。 |
|
112
FrankHB Dec 3, 2018
@binux 你给的 Go API 中的所谓 Encoding，就是一般化的能涵盖几种 Base64 变体的 radix 64 encoding scheme （ type Encoding 的文档），只是就这个包来讲，大部分 API 干的都是“ implements base64 encoding as specified by RFC 4648 ”而已。严格来说因为含义的问题这玩意儿放这里不大合适，大概作者认为这样灵活的接口比较好，也没打算拆包而已。
|
 |
113
binux Dec 4, 2018 via Android
@FrankHB 总结一下，我们的分歧在于任意替换符号表的 radix-64 算不算 base64。以及弱密钥的加密算法还算不算加密算法呗。
我认为都是，而且两者有一个成立 base64 就能被认为是加密算法，你认为都否。 |
|
115
binux Dec 4, 2018
@FrankHB #111 即使是单一编码表的 base64，依旧是满足 in such a way that only authorized parties can access it and those who are not authorized cannot
例如在论坛中，很多人用 base64 “加密” 邮箱；在这时，authorized parties 是知道 base64 的人，而 not authorized 就是爬虫和不懂技术的 hr 之类的。 前面用凯撒置换类比，放在无法替换编码表的 base64 不合适，那么因为“重新看了下 wiki ”，ROT13 就是一个更好的例子。ROT13 都能被分类为加密算法，base64 为什么不能？ https://en.wikipedia.org/wiki/ROT13 我很认同 ROT13 中的一个描述：The algorithm provides virtually no cryptographic security, and is often cited as a canonical example of weak encryption. |
 |
116
krixaar Dec 4, 2018
@binux 我个人觉得这个问题本身就不存在，网页编码搞错的时候那堆乱码也可以当密文用，只有知道切换成正确编码的人（ authorized parties XD ）才能读，编码和加密是同一个东西了，就不用讨论谁属于谁了。
|
 |
117
Aixtuz Dec 4, 2018
不太了解密码学，但听起来觉得楼上在争论的更像是某种“定义”，我觉得定义这种东西不太适合单纯的判断对错，更倾向于认为它是共同约定的前提或标准。
|
 |
118
no1xsyzy Dec 4, 2018
@binux
@FrankHB 关于 ROT13，Python 是放在 codecs 库里的，甚至你可以用 coding: rot13 让你的整个程序以 rot13 被解读。（官方的一时找不到，随便找了其他来源的 https://breakingcode.wordpress.com/2010/07/23/quickpost-hiding-your-python-source-with-rot13/ ） 实际上加密和编码的边界是模糊不定的。这里为了区分它们，先要把它们在某一方面统一起来，因其都是表达某种原信息的另外表示方法，先姑且统称“表示法”（虽然个人常称其为“结构”，但这一称呼本身依赖对世界的认识模式）。 严格来说，被证明 ZKP 的表示法叫做加密，被证伪 ZKP 的表示法叫做编码。 最大的问题是：现在任何表示法的 ZKP 并没有被证明。 换句话说，现在没有一个被证明 ZKP 的表示法，现在实际上大规模使用的都是一些没被证伪 ZKP 的表示法。 包括哈希那块，又说什么什么算法被攻陷（被证伪 ZKP ）。 |
|
119
FrankHB Dec 4, 2018
@binux 这里有个问题：“ authorized parties ”是谁决定的？很明显在现实中应该是 cryptosystem 的设计者根据需求明确的，只是有时候恰好因为其它实现性质上的假设所以有时候看起来就是实现方案蕴含的性质——这是一种 abstraction leak，有时候能妥协，但原则上是增加风险而不符合需求的性质，应尽量避免。
“ authorized parties 是知道 base64 的人，而 not authorized 就是爬虫和不懂技术的 hr 之类的”这就是拿具体实现的性质的事后诸葛亮评价了。即便结果如此，没有一个面向不特定访问者的实际用例的原本目的就是以“是否知道怎么看出并解码出 Base64 ”来区分 authorized parties 的，没谁能保证一个爬虫一定不能分析 Base64 或者一个“不懂技术的”一定不懂怎么猜出 Base64 来解码（ LZ 给的案例也是这样啊）。现实中以这种方案实现“加密”的，全是基于误解（以为不被通知是某种 Base64 这样的方法的访问者就应该没法“解密”，而事实上并没法保证不特定访问者如设计者想象中一样“不懂技术”），根本没法补全假设。非要抛开假设的可实现性，单凭这点判断区分 authorized parties 成功而具有保密性，在逻辑上是循环论证了。 与之相对，用基于 ROT-13 这样的替换式密码，或者就是用 radix-64 代替公开的 Base64 的变体，即便没解决特征明显的问题，至少能做到对不特定访问者试几次就可能直接“解密”出来，依赖这个假设补全漏洞，所以还有算作“加密”的意义。但反过来，不考虑需要补全的太弱的假设，这玩意儿可以保守地不视为加密（像 @no1xsyzy 举的例子）。 关于加密和编码，我认为一般意义上的加密是编码的子集。狭义地说，为了和满足保密性要求的编码区分，编码才排除加密。是否有必要从编码的讨论中排除加密，这点可以另外约定，看上下文需要（就像 PRNG 不一定得排除 CSPRNG 一样，反正上下文不会有歧义就行）。但（若不从编码的外延中明确排除加密）基于自然语言的自洽目的，为了使加密这个词不至于成为编码的同义反复，至少还得约定保密性要求使加密是编码的真子集，避免任意目的的编码都能算作加密，这个准则至少弱到不能明显不合理到没有现实可操作性（就 Base64 这样）。 |
|
120
binux Dec 4, 2018 via Android
@FrankHB ROT-13 不存在可替换的部分，它的算法是固定的，和 base64 是一样的。你前面的一段换成 ROT13 完全也是成立的，那么是什么使得 ROT13 算加密，base64 就不算了呢？难道知道的人多就不算加密，知道的人少就算了，那么多到什么时候不算呢？
解决这个混乱的最好方式就是承认加密和编码不存在确定的界限。 |
|
121
FrankHB Dec 4, 2018
@binux 所以说“ ROT-13 这样的”，没有 Base64 那么死——具体 Base64 的变体限定使用什么 encoding scheme 是有可查证的 spec 的，而 ROT-13 没有公认的 spec，一般只要求字母表是 26 允许编码解码使用相同操作（即便常见实现只使用拉丁字母表而不使用替换字母表的变体），于是具有和 radix-64 可比程度的在编码表的可变性。另外，英文维基上说：The algorithm provides virtually no cryptographic security, and is often cited as a canonical example of weak encryption.
|
|
122
binux Dec 5, 2018
@FrankHB #121 ROT-13 虽然没有 base64 那么正式的 spec，但是当你看到密文是拉丁字母表的时候，它的映射表就是确定的。你用你看到的字母表往后数 13 个就是了，不然它也不叫 ROT13 了
weak encryption 也是 encryption 啊。 |
|
123
no1xsyzy Dec 5, 2018
|
Select Language