我有一个要加密的流,以便向 10,000 个订阅者广播。我知道我应该使用对称密钥加密这些数据;并且还打算每 30 天轮换一次此对称密钥。
假设我已经有每个订阅者的公钥(只有他们知道的私钥),我应该如何加密对称密钥并将其发送给订阅者?
或者这很明显吗?我只是用每个公钥加密对称密钥?有什么特别需要考虑的吗?
例如,对称密钥的长度如何影响解决方案?我正在考虑将对称密钥包装在 SOAP 或 JSON 消息中,这可能会改变要加密的最终字符串的长度。
我有一个要加密的流,以便向 10,000 个订阅者广播。我知道我应该使用对称密钥加密这些数据;并且还打算每 30 天轮换一次此对称密钥。
假设我已经有每个订阅者的公钥(只有他们知道的私钥),我应该如何加密对称密钥并将其发送给订阅者?
或者这很明显吗?我只是用每个公钥加密对称密钥?有什么特别需要考虑的吗?
例如,对称密钥的长度如何影响解决方案?我正在考虑将对称密钥包装在 SOAP 或 JSON 消息中,这可能会改变要加密的最终字符串的长度。
您只需使用每个收件人的公钥加密对称。有一些关于如何做得更好的研究(以便大小开销小于,例如,每个收件人一百字节),但目前没有直接适用的。
如果您使用 RSA(这是最可能的),那么大小如下:加密消息的大小始终与模数相同;对于 1024 位 RSA 密钥,这意味着 128 个字节。加密过程包括一些填充,这会增加至少 11 个字节的内部开销。因此,要使用 1024 位 RSA 密钥加密的数据块的最大大小为 128-11 = 117 字节。
我不确定为什么要将对称密钥包装在 SOAP 或 JSON 消息中。如果它是加密的,那么接收者必须解密它;由于加密的 RSA 消息实际上看起来像一堆没有可见结构的随机字节,这意味着接收者已经知道会发生什么。那时 SOAP 或 JSON 会添加什么?也许您想反过来做,即加密(使用 RSA)对称密钥,然后将结果(128 字节加密消息)包装成 SOAP 或 JSON 消息?
有几种可用的广播加密 (BE) 方案。其中最受欢迎的是Naor-Naor-Lotspiech(NNL)于 2001 年提出 的子集差异 (SD)方案。这里是描述该方案的论文完整版本的链接: http://eccc。 hpi-web.de/report/2002/043/。AACS标准建议将其用于光盘中的数字版权管理。
任何 BE 方案的两个最重要的参数(就成本而言)是(a)存储每个用户的私钥所需的存储量,(b)必须发送的附加信息量(通信开销)加密广播的每个数据块。
已经提出了对 NNL-SD 方案的一些改进,旨在减少设备密钥存储要求以及通信开销。这里有几个。
所有这些方案都具有以下特点: A. 它们是无状态的 - 因此用户密钥不需要不时更新。B. 这些方案还允许在任何时间点撤销任意数量的用户。C. 他们还允许“黑箱叛徒追踪”。这是一种机制,通过该机制可以测试“盗版解密盒”的解密能力,以找到已在其中使用的用户密钥。可以注意到,这不需要打开盗版盒。通过将其视为黑匣子来测试其解密能力就足够了。
然而,它们有以下缺点: A. 所有广播都来自一个中心,该中心拥有有关用户密钥的所有信息 - 根据 BE 的标准定义。B.用户不能动态添加到系统中。因此,系统中的最大用户数必须在方案初始化期间进行估计并因此固定。