即时通讯安全【免费下载链接】FlyingCarpetCross-platform AirDrop. File transfer between Android, iOS, Linux, macOS, and Windows over ad hoc WiFi. No network infrastructure required, just two devices with WiFi chips (and optionally Bluetooth) in close range.项目地址https://gitcode.com/gh_mirrors/fl/FlyingCarpet点击查看免费下载Flying Carpet 是一个跨平台Android、iOS、Linux、macOS、Windows的类 AirDrop文件传输工具支持在无互联网、无网络基础设施的前提下通过临时 WiFi 热点或两台设备共处的既有网络完成加密传输。本篇技术指南以仓库根目录的 CLAUDE.md 为主体结合 Rust 核心、KotlinAndroid与 SwiftApple三套独立实现的源码与测试系统讲解其三套实现、一个线协议的架构设计、构建测试方法、v10 安全不变量Noise 加密、Preamble→Prologue 绑定、一次性 CSPRNG 密码以及仓库约定与陷阱读完你将掌握该仓库的代码布局、跨平台互操作验证机制以及修改协议时必须三端同步的底层原因。一、项目定位五平台、两种传输模式、统一端口 3290Flying Carpet 提供端到端加密、无需互联网的文件传输覆盖Android、iOS、Linux、macOS、Windows五大平台。传输方式有两种见 CLAUDE.md 开头描述Hotspot 模式热点模式一台设备创建临时 WiFi 热点另一台加入若双方都支持蓝牙则通过蓝牙自动交换热点凭证需确认配对码否则由主机显示密码及二维码供加入方输入。Shared Network 模式共享网络模式v10 新增两台设备直接使用双方已在的既有网络WiFi 或有线皆可甚至手机 WiFi 对桌面有线无需创建热点密码由接收方生成并显示发送方手动输入或扫码。两种模式全程统一使用端口 3290TCP 传输 UDP 发现均在此端口。v10 是一个破坏性版本v10 设备无法与 v9 及更早版本互传会得到明确的版本不匹配提示因此所有参与互传的设备都必须升级到 v10。这一干净断裂的版本策略由核心代码中的MAJOR_VERSION 10与 utils.rs 的is_compatible(peer_version) - peer_version 10落实。二、三套实现、一个线协议核心架构原则这是整个仓库最重要的架构事实五大平台对应三套相互独立的线协议实现任何对线上字节格式的改动发现报文、版本/模式 Preamble、Noise 握手、记录分帧都是一次破坏性变更除非在另外两套实现中同步修改否则跨端互传立刻失效。实现位置角色说明Rustcore/参考实现其余两套以其为测试基准同时交付 Windows Linux 桌面端Tauri 应用位于Flying Carpet/KotlinAndroid/FlyingCarpet/Android 端独立移植非 Rust 绑定SwiftApple/iOS macOS完整移植而非 Rust core 的绑定只能在 Mac 上构建源码上最直观的证据是core/src/下只有windows/和linux/两个平台目录而 lib.rs 用cfg_attr(target_os ...)仅在 Windows/Linux 两个target_os值上选择network/bluetooth模块整个core/中不存在target_os macos——macOS 由Apple/下的 Swift 应用独立承担两者不共享任何代码。修改 Tauri/wry/webkit2gtk相关内容只影响两个桌面平台Windows/Linux而非三个。触碰协议时必须三端同步的测试保障仓库用**跨平台已知答案测试KAT**把三套实现钉在同一字节序列上Rust 端core/src/noise.rs 中的official_noise_test_vector对照官方 cacophony 向量、psk_known_answer、discovery_key_known_answer、handshake_known_answer、prologue_known_answer发现报文向量见 core/src/discovery.rs 的test_cross_platform_vector。Kotlin 端对应的 NoiseUnitTest.kt 与 DiscoveryUnitTest.kt。Swift 端Apple/macOS/FlyingCarpetTests/FlyingCarpetTests.swift中的NoiseTests含同样的 cacophony 向量与 §9 应用级 KAT。需要注意Swift 的 KAT 只能在 Mac 上通过xcodebuild运行所以cargo test与./gradlew test全部通过并不代表Swift 侧仍然一致——这是 CLAUDE.md 明确提示的验证盲区。三、代码位置与二进制交付两者不可混为一谈仓库强调Rust 代码只构建 Windows/Linux这一事实与存在 macOS 二进制之间的区别macOS 二进制以.zip打包的.app形式发布macOS_FlyingCarpet_version.zip并非.dmg.dmg在 v8.0.1 结束v9.0.0 起改用.zip它由Apple/macOS/构建与core/无关。Homebrew 的caskbrew install flying-carpet在仓库外维护。tauri.conf.json中仍列有icons/icon.icns——这是故意保留的过期项不是 macOS 支持的证据。Swift 代码源自独立的FlyingCarpetApple仓库在 v10 发布时无历史导入因此git log对Apple/只从导入提交开始旧文档中引用的 Swift 提交哈希如 docs/bluetooth-field-guide.md 中的4c59af6、ARCHITECTURE.md 中的4a6b889/b7e9b59属于原仓库在当前仓库中无法解析。四、仓库布局速览目录内容core/Rust 核心 crateflying-carpet-corev10。平台拆分在core/src/{windows,linux}/bluetooth模块按 OS 由lib.rs中的cfg选择。关键文件lib.rsstart_transfer入口、discovery.rs、noise.rs、sending.rs/receiving.rsFlying Carpet/Tauri 桌面应用。Rust 后端在Flying Carpet/src-tauri/workspace 成员JS/HTML 前端在Flying Carpet/src/main.js、index.html。注意目录名含空格Shell 命令中需加引号Android/FlyingCarpet/Android 应用Kotlin。Noise/discovery 移植在app/src/main/java/dev/spiegl/flyingcarpet/Apple/iOS macOS 应用Swift。协议代码两平台共用位于Apple/shared/平台 UI 分别在Apple/iOS/与Apple/macOS/。改动其下任何内容前必须先读Apple/CLAUDE.mdApple 平台有独特约束无法编程创建热点故 Apple↔Apple 必须走共享网络模式BLE 无法配对 iPhone↔Macdocs/设计文档ARCHITECTURE.md描述连接角色模型五、构建与测试Rust 是一个 CargoworkspacecoreFlying Carpet/src-tauri根 Cargo.toml 使用resolver 2并将依赖在 dev 构建中也设为opt-level 3——注释明确说明snow的 ChaCha20-Poly1305 在opt-level 0下慢约 20 倍会拖慢开发构建的传输吞吐并伪装成线上问题。1. Rust 核心与桌面端cargo test # 运行全部 Rust 测试含 noise.rs / discovery.rs 中的已知答案向量 cargo build # 编译 cargo tauri dev # 运行开发版桌面应用 cargo tauri build # 构建发布产物桌面端需要 Tauri CLI 及 README.md 中列出的 Linux 依赖Ubuntu 20 示例sudo apt install libsoup2.4* libjavascriptcoregtk* libgdk-pixbuf2.0* librust-pango-sys-dev libgdk3.0* librust-atk-dev librust-atk-sys-dev librust-gdk* libwebkit2gtk* librsvg2-dev。2. Android# 在 Android/FlyingCarpet/ 目录下 ./gradlew assembleDebug # 构建 APK ./gradlew test # 运行单元测试NoiseUnitTest、DiscoveryUnitTest 等必须将JAVA_HOME设为 Android Studio 自带的 JBR捆绑 JDK否则 Gradle 会失败。3. Apple仅 macOS且不在 Cargo workspace 内# 在 Apple/ 目录下 DEVELOPER_DIR/Applications/Xcode.app/Contents/Developer xcodebuild \ -project iOS|macOS/FlyingCarpet.xcodeproj -scheme FlyingCarpet build两个项目的DEVELOPMENT_TEAM均为空因此在 Xcode 中设置自己的 team 或传入DEVELOPMENT_TEAMYOURTEAMID之前签名会失败。cargo build永远不会触碰 Apple 代码。4. 端到端加密传输测试lib.rs 中的end_to_end_encrypted_transfer测试把真实的send_file/receive_file跑在基于内存 duplex 流的 NoiseEncryptedStream之上用超过 64 KiB 的文件覆盖多个 Noise 记录验证握手、加密元数据、分块传输与逐字节文件一致性——这正是逻辑传输协议不变、只换加密传输层设计的直接证据。六、承重不变量Load-bearing InvariantsCLAUDE.md 明确列出四条**不许简化**的安全不变量它们决定了对密码学与协议层做任何改动的边界。以下逐一结合源码展开。1. v10 NoiseNoise 是唯一加密层v10 起每一次传输两种模式皆然都要完成一次Noise_NNpsk0_25519_ChaChaPoly_SHA256握手PSK 由密码经PBKDF2-HMAC-SHA256(password, saltFlying Carpet v10 shared network PSK, 600_000)拉伸得到。Noise 是唯一的密码原语——旧的逐块内层 AES 已移除v10 与 v9 是完全断裂的关系v9 对端会被拒绝。若 v10 之后还有新的 Noise 线协议变更必须升到 v11。源码对应关系core/src/noise.rs 定义了NOISE_PARAMS、PSK_SALT、PBKDF2_ITERS 600_000、DISCOVERY_INFO四个必须三端字节一致的常量derive_psk()用pbkdf2_hmac::Sha256完成 PSK 派生core/src/noise.rshandshake()基于snowcrate 构建 initiator/respondercore/src/noise.rs错误密码或篡改连接都会得到统一提示Could not establish a secure connection. Check that the password matches on both devices. (This can also mean the connection was tampered with.)EncryptedStreamS实现 tokio 的AsyncRead AsyncWrite把字节流透明地切分成 ≤64 KiB 的 Noise 记录上限 65535 字节含 16 字节 AEAD 标签因此 sending.rs / receiving.rs 中既有的发送/接收逻辑无需改动即可跑在加密流上lib.rs 中的TransferStream枚举代表PlainPreamble 阶段到Encrypted握手后的切换。Kotlin 侧是手写的NNpsk0对称状态与握手Noise.kt由于minSdk 29/ Java 8 的限制rweather/noise-java 只实现 2018 年以前的废弃 PSK 方案、jchambers/java-noise 又需要 Java 17 与 Android API 34 才有的 JCAX25519因此 Android 只在Curve25519.java从 noise-java 精简的纯 Java X25519 实现MIT 许可这一处依赖外部文件其余ChaCha20-Poly1305、HMAC-SHA256、PBKDF2全部使用 JCA。Swift 侧则按仅使用 Apple 标准密码库约束在 Apple/shared/Noise.swift 中用 CryptoKitCurve25519.KeyAgreement、ChaChaPoly、SHA-256/HMAC加 CommonCryptoPBKDF2手写实现同样的握手与记录层。2. Preamble → Prologue 绑定版本与收发模式在明文 Preamble中协商以便干净地报告版本不匹配随后 Preamble 的每一个字节都被绑定进 Noise prologue。配对双方必须以完全相同的方式构造 prologuebuild_prologue/buildPrologue构造规则为prologue u64_be(len(T_i)) || T_i || u64_be(len(T_r)) || T_r其中T_i是 Noise发起方在 Preamble 期间发送的每个字节T_r是响应方发送的每个字节发起方按我发的我收到的计算响应方按我收到的我发的计算未篡改时两边得到相同字节长度前缀保证编码无歧义。实现上Rust 用流边界包装器RecordingStream在 Preamble 阶段逐字节记录收发内容core/src/noise.rsKotlin 用RecordingInputStream/RecordingOutputStreamNoise.ktSwift 用RecordingTCPConnectionNoise.swift——在流边界记录而不是在 Preamble 函数内部记录保证协商的任何分支都不会漏掉字节。按 Noise 规范prologue 只进入h只门控握手消息 MAC不进入链密钥因此Preamble 可读但不可静默篡改对版本/模式交换的中间人篡改会使两侧 prologue 不同握手必然失败。这一点由各端的prologue_mismatch_fails_handshake负向测试守护并且PROLOGUE_RECORD_HEX与TRANSPORT_RECORD_HEX故意相同断言实现没有错误地把 prologue 混入ck。3. 密码一次性 CSPRNG接收方为每次传输用 CSPRNG 生成全新随机密码并展示绝不复用、绝不用户自选、绝不记住。整个离线破解毫无价值的安全论证详见 docs/shared-network-crypto.md 第 7 节都建立在这条不变量上。源码实现见 core/src/utils.rs 的generate_password()字符集为去掉易混淆字符的 57 符号集23456789abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ长度 10约 2⁵⁸ 的密码空间——注释指出这个长度足以使针对固定 PBKDF2 salt 的整空间预计算表在计算与存储约 EB 级上均不可行该函数需与 Android 和 Apple 保持一致。桌面端通过 Tauri commandgenerate_password暴露给前端见 main.rs。另外发现报文的 HMAC 密钥也由拉伸后的 PSK 派生derive_discovery_key(psk) HMAC-SHA256(psk, Flying Carpet v10 discovery)见 core/src/noise.rs因此线路上永远不会出现密码的快速哈希SHA256(password)仅残存于热点 SSID 的 2 字节标签与共享网络模式无关。Kotlin 对应实现为deriveDiscoveryKeyNoise.kt。4. 蓝牙仅限 Hotspot 模式共享网络模式的密码交换是手动的显示 输入/扫码不要为共享网络模式重新引入 BLE。原因记录在 ARCHITECTURE.md 的 Bluetooth Shared Network Mode 一节唯一真正需要共享模式 BLE 的是 Apple↔Apple 配对Apple 设备无法编程创建热点被迫使用共享模式而 iPhone↔Mac 恰恰无法完成 BLE 配对Apple 设计上不允许两者建立经典蓝牙配对Flying Carpet 的 GATT 特征又要求加密绑定连接因此该需求在动机最强烈的配对上行不通其余能做到 BLE 的配对几乎也都能用热点模式。所有平台在共享网络模式下都会置灰其蓝牙开关Apple 端经由bluetoothSwitchShouldBeEnabled()条件为capable connectionMode .hotspot实现这是为了修复仅按硬件能力恢复开关导致传输后开关又被重新启用的回归。Rust 核心中的强制逻辑见 lib.rsusing_bluetooth using_bluetooth connection_mode ConnectionMode::Hotspot。5. 接收方是锚点两种模式下接收方生成密码并充当 TCP 服务器Noise 响应方发送方是 TCP 客户端Noise 发起方。这与热点模式接收方即主机的平台内约定一致见 ARCHITECTURE.md 的共享网络模式章节。在共享网络模式下接收方会在发现开始之前先绑定0.0.0.0:3290的 TCP 监听lib.rs发送方发现接收方后最多重试 15 次、每次间隔 2 秒连接与 Apple 实现一致lib.rs。七、共享网络模式与发现机制补充源码细节由于 v10 新增的共享网络模式值得单独说明其发现机制这是 docs/shared-network-crypto.md 与 core/src/discovery.rs 共同描述的内容双方同时用 UDP组播239.255.73.67:3290与单播子网扫描发送 HMAC 签名的公告并监听对端公告每 500ms 一轮DISCOVERY_INTERVAL_MS。公告为固定 93 字节ANNOUNCEMENT_SIZE由421442843232的编译期断言保证字段含 magicFCAP、版本、角色0发送方1接收方、IPv4、端口、时间戳、序号、32 字节随机 nonce 与 32 字节 HMACdiscovery.rs。接收方校验magic、HMAC用密码派生密钥、时间戳窗口±60 秒、角色必须相反发送方角色在收到有效公告后解析出接收方 IP接收方角色的完成信号则是发送方的 TCP 连接本身避免 UDP 单向可达时的死锁。子网扫描在prefix_len 30或 0时退化/31、/32 无其他主机子网过大超过MAX_UNICAST_SCAN_HOSTS 1024主机时仅靠组播。发现公告的 HMAC 由拉伸后的 PSK派生见上文第六节第 3 条使一个被捕获的公告对离线攻击者而言每次猜测都要付出 60 万次 PBKDF2 迭代与握手消息的 oracle 成本一致。TCP 之上则统一走明文 Preamble版本 模式→ Noise 握手 → 加密记录层两种模式在 Preamble 之后完全一致。八、威胁模型与残余缺口理解设计意图的关键docs/shared-network-crypto.md 第 7 节给出了完整的安全属性表核心结论可概括为被动窃听者同网段、恶意运营商读不到任何内容只能对 PBKDF2 加固的离线密码破解发起徒劳尝试得益于临时 X25519 密钥的前向保密即使将来破解成功也解不开任何已发生的传输。主动中间人能被检测无法静默坐在中间读明文但完成一次与受害者的握手后会获得一个对密码的离线字典攻击机会。明确不在范围流量体积与时序每条加密记录的长度前缀明文可见Preamble 的明文可见但不可篡改已绑定进 prologue。残余的PBKDF2 加固密码 oracle发现公告与第一条握手消息的 AEAD 标签之所以在实践中无利可图靠的正是两条承重不变量密码一次性破解耗时远超单次传输的存活窗口与CSPRNG 生成破解过去的密码无助于预测未来加上前向保密恢复密码也解不开已记录流量。这就是为什么 CLAUDE.md 把不要复用密码、不要用户自选、不要记住称为模式的安全不变量而非 UI 便利。九、约定与陷阱Conventions Gotchas最后是仓库内明确的工程约定改代码前必须遵守Android改动 UI 时需保持res/layout/与res/layout-land/同步。core/Cargo.toml固定为LF行尾由.gitattributes保证不要让编辑器改写为 CRLF。头部值边界与文件名净化文件数MAX_FILE_COUNT 1_000_000见 lib.rs、文件名长度MAX_FILENAME_BYTES 8192、块大小MAX_CHUNK_BYTES 5_000_000等合理性检查以及sanitize_relative_filename拒绝..、根路径、盘符前缀等危险组件见 receiving.rs都作用于从 Noise 解密后的数据流而非原始 socket——因为 v10 中块内容以明文原始字节出现在记录层内完整性由 Noise 的 AEAD 标签保证但防内存耗尽的边界检查仍必须保留。发送端分块大小为 1 MBCHUNKSIZElib.rs而 Apple 与 Android 发送端使用 5 MB 块边界值选取保证所有合法传输都能通过。十、总结改协议前必读清单综合 CLAUDE.md 与源码对任何计划改动本仓库协议层、密码学层或连接建立的开发者最直接的行动清单是触碰连接建立、托管逻辑或 BLE 前先读 ARCHITECTURE.md四个独立角色轴传输方向 / BLE 外设-中心 / 热点主机-加入方 / TCP 服务端-客户端。触碰任何密码学、发现认证或记录/分帧层前先读 docs/shared-network-crypto.mdv10 密码学设计的规范性参考含握手字节。触碰任何平台的 BLE 代码前先读 docs/bluetooth-field-guide.md四个独立轴、七条来之不易的经验法则、平台矩阵与症状→原因排查手册历史调查日志见 docs/windows-ble-gatt-0x8000ffff.md 与 docs/ble-bond-asymmetries.md。改动线协议后三端实现Rust/Kotlin/Swift与其跨平台 KAT 必须一起更新并记住 Swift KAT 只能在 Mac 上验证。这样一套参考实现 两套移植 共享已知答案向量的架构使得一个 macOS 发送端可以和一个 Android 接收端互传每一端都在自己的单元测试里断言同一组字节向量任何标签、端序或密钥调度上的偏差都会在最早期暴露而不是在真机互传时才以握手失败、原因不明的形式出现。赞分享即时通讯安全【免费下载链接】FlyingCarpetCross-platform AirDrop. File transfer between Android, iOS, Linux, macOS, and Windows over ad hoc WiFi. No network infrastructure required, just two devices with WiFi chips (and optionally Bluetooth) in close range.项目地址https://gitcode.com/gh_mirrors/fl/FlyingCarpet点击查看免费下载相关推荐Flying Carpet v10 共享网络模式加密设计全解析基于 Noise NNpsk0 的密码认证临时密钥交换Flying Carpet v10 共享网络模式加密设计全解析基于 Noise NNpsk0 的密码认证临时密钥交换 本篇文章以 docs/shared ne即时通讯安全slopus/happy-wire 线协议包解析Happy 客户端与服务端共享的加密会话消息契约slopus/happy wire 线协议包解析Happy 客户端与服务端共享的加密会话消息契约 导读 slopus/happy wire 是 Happy人工智能AI AgentAI 应用移动开发CLI后端Fluxer API 开发者指南协议面、共享契约与端点发现全解析Fluxer API 开发者指南协议面、共享契约与端点发现全解析 Fluxer 是一个可自托管self hostable的开源即时通讯与 VoIP 聊天平上一篇告别臃肿控制台3分钟掌握惠普暗影精灵笔记本性能调校新方案下一篇Hugo 中 hugo.WorkingDir 详解模板内获取项目工作目录的实现原理与实战用法创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考