安全与限制
实验性软件
Krypt04Mcg 和 Krypt04McgRelay 由 AI 辅助生成，尚未经过独立安全审计。协议、实现和密码设计可能存在漏洞或设计缺陷。不要用于生产环境，也不要用它保护敏感、重要、私密、受监管或高价值数据。
这里概述上游 README 声明的设计与限制，不是独立安全审计，也不是安全性保证。需要成熟加密通信时，上游建议考虑 Signal 或 SimpleX 等已有工具。
上游使用声明
构建环境、发布产物、依赖与运行行为按现状提供，不保证安全、可信、无病毒或适合特定用途。上游建议在虚拟机等隔离环境使用，并尽可能在安装前用 VirusTotal 或同类服务检查构建产物。
项目不承诺长期积极维护、安全响应或兼容性更新。发布 JAR 的签名可以用于校验它与所持公钥的对应关系，不能证明实现或构建环境本身安全。
聊天密码设计
- 使用 AES-256-GCM 或 ChaCha20-Poly1305，并为每条消息生成随机 96 位 nonce，不使用 AES/ECB。
- 使用 HKDF-SHA256 从 KEM 共享秘密派生 AEAD 密钥，以消息 ID 为 salt，不直接把 KEM 秘密当作密钥。
- 消息 ID、nonce、KEM 随机数与会话材料由
SecureRandom生成。 - v3 的 AEAD AAD 覆盖版本、类型、标志、发送者、接收者、时间戳、消息 ID 及存在的算法标识。
- 包中的 KEM 和签名算法标识必须与对应存储密钥匹配；签名覆盖 AAD 以及时间戳、nonce、KEM 封装和密文。
- 接收者错误、解密失败或签名无效不会当成正常明文显示；不信任身份在解密和会话变更前被拒绝。
身份和首次信任
首次导入依赖 TOFU。要建立更强的身份绑定，应通过可信的游戏外渠道核对完整 KEM 和签名指纹，并用 key verify 确认。
经过认证的包发送者必须与外层 Minecraft 发送者匹配。缺少经过认证发送者的系统消息传输，只接受签名包或已绑定身份的 AEAD 会话消息。
会话与重放
exchange 是签名的两消息握手。发起者生成内存中的一次性 KEM 密钥，响应者把新会话材料加密给这个临时公钥，并把双方身份、UUID、两对指纹、会话 ID 和请求消息 ID 绑定到交换 transcript。临时私钥在响应接受或短时超时后销毁。
这种设计意图避免后来长期 KEM 私钥泄露直接解密已记录的交换响应，但并不构成经审计的全面前向保密承诺。
时间戳接受窗口有界，重放记录按发送者保留；v4 会话消息认证会话 epoch 和单调序号后才推进计数。旧 v1–v3 会话消息被拒绝。
服务端可见性
中继不解密消息正文，但需要看到路由信息。聊天包头的发送者、接收者以及流量大小和时序等信息并非全部隐藏。默认聊天传输在没有中继时还可能广播加密片段。
“服务端不打印加密载荷”只描述本插件的日志行为，不能代表服务器、其他插件或网络中的所有观察者都没有记录。
运行限制
聊天过滤、签名、速率限制和反垃圾插件可能干扰大包。传输可能分片、超时或因过载丢弃。可选 API / 文件共享需要兼容中继；流 READY 不是远端数据完成回执。
本地磁盘加密不能防止已控制当前用户进程或设备的攻击者访问运行中的数据。备份需保留原始存储主密钥与相应系统环境，详见密钥与存储。
报告问题
上游请求将代码安全问题、版权或许可问题反馈到对应仓库 Issues：
来源：客户端 README、插件 README。