1 个不稳定版本
0.1.1 | 2024年5月2日 |
---|---|
0.1.0 |
|
#345 在 密码学 中
30KB
500 行
ECDH-OMR:基于ECDH的匿名消息检索
ECDH-OMR旨在解决以下问题
- Alice想在一个服务器上给Bob留一条消息。
- 服务器不应该知道这条消息是给Bob的。
- Eve既不能统计服务器上可取回的真实消息的数量,也不能判断是否有新消息到来或者旧消息被删除。
- Bob应该能够从服务器上取回他们的消息,而服务器不知道是否发生过这种情况。
ECDH-OMR通过使用Diffie-Hellman密钥交换的交换性质来实现一种公钥[遮蔽]形式,允许第三方向第三方无法识别的接收者发送消息。这是一种隐私信息检索的形式。
此库使用x25519-dalek以及(通用地)使用RustCrypto的elliptic-curves和它们的AEADs(再次,通用地)来实现此方案。
警告 此工作尚未经过独立审计
尽管其核心方案已收到初步审查并获得积极结果,但在考虑其使用之前,应发布更严格的证明。实现是针对此方案可能具有的合理通用API的初步尝试,迄今为止尚未收到任何审查。
仅限实验性使用和研究。
基础知识
尽管其使用并不广泛,但ECDH支持多个参与者之间的共享秘密。实际上,这个方案之所以有效,是因为以下两个陈述是等价的
- ECDH ( ServerSK, ECDH ( AliceSK, BobPK ) )
- ECDH ( BobSK, ECDH ( ServerSK, AlicePK ) )
这允许服务器(或另一个第三方)为不知道真实公钥的接收者加密信息,并且接收者可以解密信息而无需向服务器(或另一个第三方)识别他们。
方案流程
以下分析中,Alice向Bob发送一个未加密的消息。Alice如何加密消息给Bob,需要通过使用此方案的不同协议层来处理。
- Alice获取了Bob的公钥。Alice对Bob的公钥进行盲化。这是通过生成一个临时的秘密密钥,并使用它来与Bob的公钥创建一个共享密钥来完成的。这个共享密钥是Bob的盲化公钥(BK)。临时的秘密密钥的公开对应物作为盲化因子(BF)。这两个都和消息一起发送到服务器。
Alice → 服务器- BlindedBobBK = ECDH ( EphemeralSK, BobPK )
- BlindedBobBF = G^EphemeralSK
- 消息
- 为了处理请求,服务器生成自己的临时(针对请求)密钥对,并将其与Bob的盲化公钥及其盲化因子结合。生成一个随机数,并使用它与生成的共享密钥一起对称加密消息。
服务器 → 任何人- BlindedBlindingFactorBK = ECDH ( RequestSK, BlindedBobBF )
- 随机数
- 消息密文 = AEAD Enc ( ECDH ( RequestSK, BlindedBobBK, 随机数, 消息) )
- 尽管服务器不知道Bob的真实公钥,Bob现在收到了来自服务器的加密消息。Bob还收到了他们需要恢复Alice留下的消息的所有信息。
Bob → Bob- 消息 = AEAD Dec ( ECDH ( BobSK, BlindedBlindingFactorBK ), 随机数, 消息密文)
API流程
有关包含“诱饵”或的注释版本,请参阅examples/decoyed.rs
,它还展示了诱饵提示的使用。[链接](https://codeberg.org/reach/reach/src/branch/main/common/examples/decoyed.rs)
use ecdh_omr::*;
use x25519_dalek::*;
use rand_core::OsRng;
type Hint = ecdh_omr::Hint<X25519, ocb3::Ocb3<aes::Aes128>, 32>;
fn main() {
// Bob
let bob_secret = StaticSecret::random_from_rng(&mut OsRng);
let bob_public = PublicKey::from(&bob_secret); // -> Alice
// Alice
let bob_blinded_by_alice = bob_public.blind(&mut OsRng); // -> Server
let alice_message = [42u8; 32]; // -> Server
// Server
let hint = Hint::new(&bob_blinded_by_alice, &alice_message, &mut OsRng).unwrap(); // -> Bob
// Bob
let bob_recovered_message = bob_secret.try_to_take_the(&hint).unwrap(); // ✅
assert_eq!(alice_message, bob_recovered_message);
}
注释
API文档
…是的,这是必要的。这将会存在。很快。承诺✨
规模
从根本上讲,由于它是一个基于轮询的方案,而不是例如模糊消息检测,其中服务器执行匹配工作,其规模受带宽和计算的限制。
后量子考虑因素
CSIDH/CTIDH在技术上支持此方案,但研究得不够充分,目前无法实现。然而,由于ECDH-OMR的规模限制,CTIDH-OMR或ECDH-CTIDH-OMR在特定情况下可能是可用的。
ML-KEM不是交换的,因此这需要一种方式让第三方在不更改嵌入的秘密的情况下更改密文。我们不知道这是否可能。
致谢
基于ECDH的无密钥消息检索由@eaon作为Reach的一部分开发,Reach是一个端到端加密通信平台,旨在为希望允许匿名个人与他们联系以提供信息或请求的协作小组而设计。到目前为止,Reach以及导致此项目的相关研究都是自筹资金的,如果您想改变这一点,请联系我们😉
作者还向SecureDrop的E2EE协议研究贡献了该方案。
- 作者想感谢Davide @TheZero对上述研究早期贡献,其中使用多党Diffie-Hellman密钥交换的非常规用途在挑战/响应协议中临时“证明”了密钥持有。
- 作者还想要感谢Jacob Young,他强调了挑战/响应协议如何使服务器能够快速关联消息并推断接收者的身份属性,这促使作者再次着手解决这个问题。此外,还要感谢他在[Recurse Center]花费更多时间来审查在这个crate中实现的基于ECDH的匿名消息检索方案。🐙
依赖项
~1.5–3.5MB
~64K SLoC