发表机构
New York University Abu Dhabi（纽约大学阿布扎比分校）
机构由 AI 辅助整理，请以论文原文为准。AI 中文总结
SEEK提出结合同态加密与安全两方计算的加密关键词搜索协议，实现高效隐私保护消息检测，显著降低开销并提升速度。
AI 中文摘要
加密通信保护了敏感用户数据，但可能助长有害或非法交流，从而在检测危险消息与保护终端用户隐私之间产生了权衡。为解决这一问题，我们提出了SEEK，一种实用且高效的加密关键词搜索协议，用于隐私保护消息传递，该协议将同态加密与安全两方计算（2PC）相结合。SEEK首先将消息划分为具有最小充分重叠的密文片段，然后使用加密的关键词陷门对其进行同态关联。对于长消息，该设计可将发送方加密和上传开销相比最先进的基线降低最多两个数量级。它支持ASCII不区分大小写的匹配，每个片段使用一个固定大小的加密陷门和一次同态乘法，相比最强的基于分片的基线，关联计算速度最多提升5.47倍。随后，SEEK调用基于2PC的选择性解码、盲化零测试和安全聚合，仅揭示关键词存在或不存在的比特，同时隐藏关键词、其长度、消息内容、匹配计数和位置。在导致精确匹配失败的大小写变体情况下，SEEK实现了100%的准确率，无需额外的陷门或在线通信。我们进一步将SEEK实现为端到端的Web和跨平台移动应用。在每周消息历史的原型评估中，每次搜索的在线计算时间为1.92秒，证明了SEEK的实际可行性和效率。
英文摘要
Encrypted communication protects sensitive user data but can facilitate harmful or unlawful exchanges, creating a trade-off between detecting dangerous messages and preserving end-user privacy. To address this, we propose SEEK, a practical and efficient encrypted keyword-search protocol for privacy-preserving messaging that combines homomorphic encryption with secure two-party computation (2PC). SEEK first partitions messages into ciphertext fragments with the minimum sufficient overlap, then homomorphically correlates them using encrypted keyword trapdoors. For long messages, this design can reduce sender-side encryption and upload overhead by up to two orders of magnitude over state-of-the-art baselines. It supports ASCII case-insensitive matching with one fixed-size encrypted trapdoor and one homomorphic multiplication per fragment, yielding up to 5.47x faster correlation computation than the strongest fragmentation-based baselines. SEEK then invokes 2PC-based selected decoding, blinded zero testing, and secure aggregation, revealing only the keyword presence-or-absence bit while hiding the keyword, its length, message contents, match counts, and locations. SEEK achieves 100% accuracy under case variations that result in exact-matching failures, without requiring additional trapdoors or online communication. We further realize SEEK as an end-to-end web and cross-platform mobile application. Prototype evaluation on a weekly messaging history yields an online computation time of 1.92 s per search, demonstrating the practical feasibility and efficiency of SEEK.
