安全与隐私github.com
age：简单、现代且安全的文件加密工具
Age: A simple, modern and secure file encryption tool
2019 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
age 是由知名 Go 密码学开发者 FiloSottile 打造的极简文件加密工具，旨在用现代密码学原语（X25519、ChaCha20-Poly1305 等）取代臃肿难用的 PGP/GPG。它提供小巧的密钥格式和简单的命令行体验，多次登上 HN 首页，成为文件加密领域备受关注的新方案。
为什么经久不衰：它以极简、现代的设计填补了 PGP 之后文件加密工具的空白，多年来反复被社区讨论，是理解现代加密工具设计理念的经典案例。
HN 评论精选
age 方向正确，但加密工具的真正瓶颈在于普及和易用性，而非技术本身
这太棒了，它填补了我一直坚持认为是 PGP 仅存合理用途的空白。当然，现在还需要解决普及问题。尽管 PGP 的普及率早已是个笑话，但所有旨在取代它的工具（即时通讯领域除外）的使用率反而更低。Magic Wormhole 发布已近五年，Latacora 那篇著名文章推荐它传文件也过去半年了，可你至今仍找不到可靠的 Windows 版本，更别说 GUI 了。这些项目大多源于普通用户对更好替代方案的真实需求，但很少有项目真正做出了对普通人更易用的产品。
bscphil查看英文原文
This is great, it fills a gap that I've long defended as PGP's remaining legitimate use case. Of course, now we just need to work on the adoption problem. Despite the fact that PGP adoption is a well-known joke in itself, all the tools designed to replace it (with the exception of the IM space) have somehow managed to achieve even lower use rates. It's been almost five years since Magic Wormhole first released, and about half a year since that popular Latacora post recommended it for transferring files, and said "Someone stick a Windows installer on a Go or Rust implementation of Magic Wormhole right away". Guess what you're still not going to find a reliable Windows build (let alone a GUI) for? Yep that's right. Despite the fact that most of these projects come from a felt need for better alternatives to PGP for the average user, very few of them have actually come up with a product that's more accessible to the average person.
希望 age 明确安全目标，并为 X25519 提供发送者认证支持
有没有关于安全目标和密码学设计的详细说明？比如使用 scrypt 时能得到完全认证的加密：消息必然来自知道密码的人。但使用 X25519 时采用的是 ECIES 方案，没有发送者认证，只有 IND-CCA 安全。格式文档说想要“签名”就用 minisign/signify，但我怀疑大多数人想要的是来源认证。从签名和加密的通用组合获得公钥认证加密其实非常困难，细节繁多。age 最好能像对 scrypt 那样直接为 X25519 支持这一特性。
nmadden查看英文原文
Is there a detailed description of the security goals and crypto rationale anywhere? For example, it seems that if you use scrypt then you get fully authenticated encryption: the message must have come from somebody who knows the password (either a trusted user or you chose a weak password). But if you use X25519 then the scheme used is ECIES, so no sender authentication, only IND-CCA security. The format document says that if you want “signing“ then use minisign/signify, but I suspect most people want origin authentication. We know that it is actually quite hard to obtain public key authenticated encryption [1] from generic composition of signatures and encryption, with many subtle details. It would be better if age supported this directly for X25519 as it does for scrypt. Unfortunately, you can’t simply use a static key pair to achieve this (as in nacl’s box) as age uses a zero nonce to encrypt the file key with chacha20-poly1305 so reusing a static key will result in nonce reuse. (This seems a bit fragile). [1]: https://eprint.iacr.org/2001/079
对规范细节提出多项技术疑问，指出文档存在模糊之处
对规范的一些问题：1. age 如何区分 -r 参数中的文件名和其他密钥格式？2. 头部用的是标准 Base64 还是 URL 安全 Base64？规范听起来像标准 Base64，但示例中有些行含 -_ 有些含 +。3. 头部允许哪些字符？仅限 ASCII？4. recipient 类型、参数中是否禁止某些字符？5. 头部行开头哪些字符串有特殊含义？6. CRLF 规范化是否也适用于非 ASCII armored 文件？7. 保密公钥以实现对称认证加密是否是官方支持的用法？8. 命令如何……
CodesInChaos查看英文原文
Some questions about the spec: 1. How does age disambiguate between filenames and other key formats for the -r argument? (Those formats are also valid filenames) 2. Does the header use normal Base64 (i.e. +/) or url-safe Base64 (i.e. -_). The specification sounds like normal Base64, but some lines of the example contain -_ others contain +. 3. What characters are allowed in the header? ASCII only? (the current key-formats are ASCII only, but an implementation is supposed to skip unknown formats) 4. Are any characters forbidden in recipient types, arguments and additional lines? 5. Which strings at the beginning of a header line have special meaning and thus are illegal for additional lines? Only `-> ` and `--- `? I assume the space is mandatory in those strings despite the spec not mentioning that for `->`? 6. CRLF normalization of the header is only mentioned in the section about ascii-armored files. I assume it also applies to non ASCII armored files? 7. Is keeping the public key secret to achieve symmetric authenticated encryption an officially supported/recommended use-case? (If the public key is public, the MACs block decryption oracles. However they don't provide any authentication, because the message isn't bound to any sender and thus an attacker can just encrypt their own message to your public key. If the receiver's public key is secret, this isn't possible and thus the current implementation provides symmetric sender authentication) 8. How does the command line tool signal failure/truncation/corruption?
认为 X25519 密钥强度偏低，并质疑中途认证失败时的处理方式
NSA 建议停止使用低于 384 位的 ECC。对于 ed448 这类方案带来的额外时间和空间开销，某些应用难以接受，但文件加密通常不属于这类应用，所以我觉得有点失望。不过 NIST 后量子标准应该很快会定稿，届时这会被与后量子方案混合的方案取代。另外，如果认证在文件中途失败会怎样？是在 stdout 输出截断的解密结果，还是把整个输入缓存在内存里？
nullc查看英文原文
NSA recommended people stop using ECC <384 bits (https://apps.nsa.gov/iaarchive/programs/iad-initiatives/cnsa-suite.cfm). There are applications where the extra time and space of something like ed448 present uncomfortable trade-offs. File encryption is not generally one of those applications. So I find this a little disappointing. But I suppose that NIST PQ will finalize in the not far future and this will get replaced by something that hybridizes with a PQ scheme. (I say replace because the expectation that a pubkey is something you can easily copy and paste doesn't really work with the PQ schemes you'd likely use with file encryption.) What happens if auth fails part way through the file? Do you get a truncated decryption on stdout? -- or is this buffering the whole input in memory?
历次讨论
同类还值得读
非法素数
Illegal prime
维基百科条目，介绍“非法素数”：某些素数之所以被称为“非法”，是因为它们经特定编码后，恰好对应一段被法律禁止传播的数据——最著名的是 DVD 解密程序 DeCSS 的代码，有人把…
安全与隐私上首页 5 次 · 2010–2021en.wikipedia.org编辑精选关于 /dev/urandom 的常见误区
Myths about /dev/urandom
（Thomas Hühn 撰写，2014 年首发并持续更新）逐条反驳关于 /dev/urandom 的常见误解：它与 /dev/random 使用的是同一个 CSPRNG，一旦完…
安全与隐私上首页 5 次 · 2014–20202uo.de编辑精选AES 高级加密标准火柴人图解
A Stick Figure Guide to the Advanced Encryption Standard (AES)
一篇用火柴人漫画形式讲解 AES（高级加密标准）算法的经典科普文章。
安全与隐私上首页 5 次 · 2009–2022moserware.com编辑精选指纹是用户名，不是密码
Fingerprints are Usernames, not Passwords
作者（eCryptfs 维护者、Ubuntu 安全工程师）认为指纹等生物特征是公开、不可更改的标识，应视作用户名而非密码，不能当作秘密凭据用于认证。
安全与隐私上首页 4 次 · 2013–2017blog.dustinkirkland.comHTTPS 连接的最初几毫秒（2009）
The First Few Milliseconds of an HTTPS Connection (2009)
逐毫秒拆解一次 HTTPS 连接建立时发生了什么，重点讲 TLS 握手、证书验证、RSA 签名与密钥协商等机制，面向不熟悉该领域的读者。
安全与隐私上首页 4 次 · 2009–2020moserware.com编辑精选