#Cryptographically Secure Random Number Generation S1

中文标题：加密安全随机数生成

#ECMAScript 加密安全伪随机数生成（CSPRNG）

本提案建议添加一个用户可调用的函数，用于将 TypedArray 关联的 ArrayBuffer 部分填充为加密安全的伪随机数值。

本提案的部分内容源自 Web Cryptography API

#状态

阶段： 1
推动者： Ron Buckton (@rbuckton)

有关本提案的详细状态，请参见下面的 TODO。

#作者

• Ron Buckton (@rbuckton)

#动机

https://github.com/tc39/proposal-uuid 的关键问题之一是 ECMAScript 语言中缺乏加密安全伪随机数的“事实来源”。虽然浏览器和 NodeJS 等宿主提供了 CSPRNG（加密安全伪随机数生成器）的实现，但 ECMAScript 语言本身没有提供一种机制来供给 CSPRNG，供 UUID 等提议的 API 使用。

#目标

• 在语言内为生成加密安全的伪随机值提供单一的“事实来源”。
• 提供单一的位置来模拟 CSPRNG，而不是在每个 TypedArray 原型上提供方法。
• 如果在 ECMA-262 中引入新的 crypto 全局命名空间用于加密相关 API，我们应该确保 Web 加密 API 可以在此之上分层构建。

#现有技术

• Web Cryptography API: crypto.getRandomValues
• NodeJS: crypto.randomFillSync

#API

我们仍在研究本提案的 API 表面。预期的 API 是一个用户可调用的函数，调用时执行下面的 FillRandomValues 抽象操作。

阶段 0 的 API 提案将其公开为静态的 ArrayBuffer.fillRandom 方法，尽管我们仍在继续研究这个领域。

#抽象操作

#FillRandomValues (view)

当使用参数 view 调用抽象操作 FillRandomValues 时，采取以下步骤：

1. 执行 ? RequireInternalSlot(view, [[TypedArrayName]])。
2. 断言：view 具有 [[ViewedArrayBuffer]]、[[ByteLength]] 和 [[ByteOffset]] 内部插槽。
3. 如果 view.[[TypedArrayName]] 不是 "Int8Array"、"Uint8Array"、"Uint8ClampedArray"、"Int16Array"、"Uint16Array"、"Int32Array"、"Uint32Array"、"BigInt64Array" 或 "BigUint64Array" 之一，抛出 TypeError 异常。
4. 令 buffer 为 view.[[ViewedArrayBuffer]]。
5. 如果 ! IsDetachedBuffer(buffer) 为 true，抛出 TypeError 异常。
6. 令 byteLength 为 view.[[ByteLength]]。
7. 如果 byteLength 大于 65536，抛出 RangeError 异常。
8. 令 byteOffset 为 view.[[ByteOffset]]。
9. 令 byteEndOffset 为 byteOffset + byteLength。
10. 用加密安全的随机值覆盖 buffer 中从索引 byteOffset（含）到索引 byteEndOffset（不含）的元素。
11. 返回 view。

注意
实现应使用成熟的加密伪随机数生成器生成加密安全的随机值，该生成器使用高质量的熵种子，例如来自操作系统熵源（例如 "/dev/urandom"）。本规范对加密安全随机值中存在的信息论熵没有下限要求，但实现应尽最大努力提供尽可能多的熵。

注意
此接口定义了获取加密安全随机值的同步方法。虽然某些设备和实现可能支持真正的随机加密数生成器或提供在熵不足时阻塞的接口，但不鼓励实现使用这些源来实现 getRandomValues，既出于性能考虑，也为了避免耗尽系统的熵。相反，这些源应用于为加密伪随机数生成器提供种子，然后该生成器可以有效地返回合适的值。

#参考

• Web Cryptography API
• UUID 提案

#前期讨论

• CSPRNG“事实来源”的单独提案: https://github.com/tc39/proposal-uuid/issues/37

#TODO

下面是通过 TC39 提案流程各个阶段推进的高级任务列表：

#阶段 1 进入标准

• 确定了一位将推进添加的“推动者”。
• 概述问题或需求以及解决方案大致形态的说明。
• 说明性的示例。
• 高级 API。

#阶段 2 进入标准

• 初始规范文本。
• 转译器支持（可选）。

#阶段 3 进入标准

• 完整规范文本。
• 指定的审查者已对当前规范文本签字确认。
• ECMAScript 编辑器已对当前规范文本签字确认。

#阶段 4 进入标准

• 已为主要使用场景编写 Test262 验收测试并合并。
• 通过验收测试的两个兼容实现：[1]、[2]。
• 已向 tc39/ecma262 发送带有集成规范文本的拉取请求。
• ECMAScript 编辑器已对拉取请求签字确认。