用密码学惯用的单位去衡量密钥、摘要和熵
密码学报数用位，存东西用字节。标准给算法起名字时用的是安全参数——AES-256、SHA-512、Ed25519；而躺在密钥管理服务、缓冲区或加密机槽位里的密钥材料，量的却是字节。这中间换错了绝不只是难看而已：本该放 32 字节随机密钥的地方塞进一个 32 字符的口令，选这套算法时指望的强度就悄悄没了大半。
位 = 字节 × 8。所以一份 32 字节的密钥是 32 × 8 = 256 位——正好是 AES-256 要的密钥长度，也正好是 SHA-256 输出的摘要长度。位是安全强度的单位，因为强度说的是攻击者要搜多少种不同取值；字节是存储与传输的单位。几乎每一次密钥管理评审都要在这两者之间来回换算，而且往往是一边换一边盯着某个库里写着 keyLen 却没说单位的函数签名。
对称密钥
非对称密钥
密钥的熵
上线前核一遍密钥长度
量原始材料，别量编码后的样子
取解码之后那份密钥的字节长度。Base64 大约会撑大三分之一，十六进制直接翻倍，所以 44 个字符的 Base64 串和 64 个字符的十六进制串，说的其实是同样的 32 个原始字节。
把它填进字节一栏
位数随打随出，于是你可以依次试 16、24、32 字节，眼看着 AES-128、AES-192、AES-256 三道分界线跳出来。逗号和点都能当小数点用，空格会被忽略。
把数值复制进规范或工单
每一栏都有自己的复制按钮，给出的是不带单位的纯数字——要把这个数写进威胁模型、密钥轮换手册或某个配置常量时非常省事。
反过来给缓冲区定长
标准丢给你一个位数、而你要按字节申请空间时，把两栏交换一下即可——比如 384 位摘要对应一个 48 字节的数组。要衡量的不是单个密钥而是整套证书包时，可搜索的下拉菜单里也有千字节。
密钥与摘要长度：算法、位数、字节数并排看
某个库拒收你的密钥材料时，大多数人真正想查的就是这张表。注意 RSA 那一行跟其他行不一样：它的字节长度很大，安全强度却不是。
| 算法或取值 | 标称长度（位） | 原始存储（字节） | 十六进制字符数 |
|---|---|---|---|
| AES-128 密钥 | 128 | 16 B | 32 |
| AES-256 密钥 | 256 | 32 B | 64 |
| SHA-1 摘要 | 160 | 20 B | 40 |
| SHA-256 摘要 | 256 | 32 B | 64 |
| SHA-512 摘要 | 512 | 64 B | 128 |
| UUID（版本 4） | 128 | 16 B | 32 |
| Ed25519 私钥种子 | 256 | 32 B | 64 |
| RSA-2048 模数 | 2 048 | 256 B | 512 |
版本 4 的 UUID 最能说明「长度」和「强度」不是一回事：它占 128 位，其中六位是固定的版本位和变体位，真正随机的只有 122 位。
评审时两栏都能改
任意一侧输入数值，另一侧立刻更新，于是设计评审可以在「RFC 写的是 384 位」和「我们的缓冲区是 48 字节」之间来回跳，不用重新敲一遍。
大数值依然好认
千位之间用空格分隔，特别大的数会切到科学计数法，衡量的对象是整个密钥库而不是单个密钥时格外有用。
不止能算一份密钥
两侧可搜索的单位菜单里还有千字节和兆字节，所以密钥包、吊销列表或导出的密钥库都能在同一个页面上算。
数值不出浏览器
页面加载完之后所有算术都在本地完成，从真实密钥清单里抄下来的长度不会被发往任何服务器。
密钥定长相关问题
AES-256 的密钥为什么只有 32 字节？
名字里的 256 是以位为单位的密钥长度，而 256 ÷ 8 = 32 字节。这份密钥是纯随机材料，没有头部、没有校验、没有编码，所以一位都不浪费。如果某个库要 32 字节而你给了它一个 32 字符的口令，长度是对上了，不可预测性却没有——这正是带盐、高迭代次数的密钥派生函数要弥补的地方。
RSA-2048 才 2 048 位，为什么密钥文件有好几千字节？
2 048 位说的只是模数，也就是 256 字节。私钥文件还要存两个素因子、私钥指数和一组中国剩余定理参数，用 ASN.1 结构包起来，再 Base64 编码成 PEM——每一步都会加字节。公钥文件之所以小得多，是因为它只带模数和一个很短的指数。
一句口令到底有多少位的熵？
熵取决于口令是怎么生成的，而不是它有多长。从一个 7 776 词的词表里等概率随机抽词，每个词约贡献 12.9 位，所以五个词的口令大约 64 位，哪怕它在磁盘上占了三十几个字节也一样。字节数相同、但由人自己想出来的口令，价值要低得多，因为那些选择从来都不是均匀的。
128 位的 UUID 当会话令牌够随机吗？
版本 4 的 UUID 是 16 字节，其中四位编码版本、两位编码变体，剩下 122 位是随机的。抵御猜测绰绰有余——前提是它出自密码学安全的随机源，而很多 UUID 实现并不保证这一点。版本 1 更糟，因为它里面嵌了时间戳和 MAC 地址。要做令牌，还是直接生成 32 个随机字节。
哈希输出为什么总是按位数说，而不是按字节数？
因为决定抗碰撞能力的是位数：按生日界，n 位的摘要大约提供 n / 2 位的抗碰撞强度，所以 SHA-256 抗碰撞约为 128 位。叫它「32 字节的哈希」就把这层关系藏起来了。把摘要截短做短指纹时道理相同——该保留多少，也是按位数来争论的。
还没有评论，快来发表第一条！