# VeilMesh - Full AI-Scraping Context & Technical Reference This document serves as a full-text technical reference containing all primary FAQs, whitepaper segments, and security audits for the VeilMesh protocol. --- ## 1. Frequently Asked Questions Reference ### Registration & Identity - **Q: Do I need a SIM card, phone number, or email to register?** - **A:** No. VeilMesh does not require any personal identifiers to function. Your identity is a raw cryptographic public key generated securely on your device. You can add friends by scanning their QR code or pasting their unique Veil ID. ### Privacy & Encryption - **Q: Can the developers of VeilMesh read my messages?** - **A:** No. All conversations are secured using state-of-the-art End-to-End Encryption (E2EE). The messaging core implements the Double Ratchet Algorithm for 1-on-1 chats and Messaging Layer Security (MLS) for group chats. The servers acting as blind relays have zero capability to inspect or decrypt your payloads. - **Q: What metadata does the relay server collect?** - **A:** None. By utilizing Sealed Sender technology, the sender's identity wrapper is encrypted using the recipient's public key. The relay server only processes opaque transport packets. It knows which hash destination to forward a packet to, but has zero knowledge of who sent it, when they created it, or what it contains. - **Q: What happens if a government or law enforcement agency requests data from your relay servers?** - **A:** Because VeilMesh operates on a zero-knowledge architecture, we do not store chat logs, IP logs, metadata mapping, or identity profiles. If we receive a legal subpoena or government request, we have zero data to provide. In the case of real-time server surveillance, an observer would only see encrypted, anonymous binary packets passing through, with no ability to read their contents or identify the senders. ### Device Security - **Q: Where are my private keys stored?** - **A:** Your private cryptographic keys (Ed25519 for signing and X25519 for key agreements) are generated and stored exclusively within your device's hardware-backed cryptographic chips—the Secure Enclave on iOS or Keymaster/Keystore on Android. They never leave the physical silicon of your device. - **Q: What happens if I lose my phone? Can I recover my chats?** - **A:** No. VeilMesh does not store your chats or keys on central servers. If you lose your device, your data is gone forever. To prevent this, regularly export password-protected database backups and save your Veil ID backup seed phrase in a secure location. ### Offline Mesh Operations - **Q: How far does the offline connection reach?** - **A:** Bluetooth Low Energy (BLE) covers a radius of 10 to 30 meters depending on physical obstacles like concrete walls or metal compartments. Wi-Fi Direct can reach up to 100 meters. Because VeilMesh uses multi-hop routing, messages can hop through intermediate devices, extending the network range far beyond a single connection. - **Q: Does running a mesh network drain my battery?** - **A:** We have optimized background scheduling in the Rust Core to minimize active radio usage. Instead of scanning constantly, the app transitions into low-power states when locked, and utilizes optimized Apple APNs/Firebase Cloud Messaging VoIP push events to wake the signaling pump only when incoming packets are available. - **Q: What happens if a node routing my message is malicious?** - **A:** Nothing. Because all messages are fully encrypted end-to-end, intermediate nodes in the mesh can only see ciphertext (encrypted data). If a node attempts to modify the packet, the recipient's device will immediately detect a verification failure and discard it. Spam is dropped instantly using O(1) Proof-of-Work checks. - **Q: What if a government or internet provider blocks the relay servers?** - **A:** If the internet is completely unavailable, VeilMesh operates offline in local mesh mode. If internet access is available but our relays are censored, the core engine uses built-in traffic obfuscation protocols (like TLS tunneling and Shadowsocks wrappers) to bypass provider blocks. --- ## 2. Protocol & Whitepaper Technical Summary ### Hybrid Routing Protocol VeilMesh merges two routing paradigms into a single unified engine: 1. **Ad-Hoc Offline Routing:** Nodes discover adjacent peers using BLE advertisements and Wi-Fi Direct. Packets are broadcasted using an epidemic epidemic gossip routing algorithm. Every node acts as an autonomous router, verifying packet signatures and relaying them if the TTL is valid. 2. **Online Transit Routing:** When a node detects internet connectivity, it establishes connections to configured Blind Relays via WebRTC or TLS-wrapped sockets. If the target recipient is online elsewhere in the world, the relay routes the packet to their active connection pool. ### Sealed Sender Protocol Traditional envelopes contain: `[Sender ID, Recipient ID, Encrypted Payload]`. VeilMesh wraps packets using: `[Recipient ID, Encrypted Envelope: [Sender ID, Encrypted Payload]]`. The relay server can decrypt only the outer wrapper to identify the target Recipient ID. It has no access to the inner envelope containing the Sender ID, achieving sender anonymity. ### Group Chats (MLS Protocol) Instead of pairwise key agreements (which scale $O(N)$ in bandwidth and CPU overhead), group chats utilize Messaging Layer Security (MLS / RFC 9420). MLS establishes a tree-structured group key. - **Efficiency:** Adding, updating, or removing members requires $O(\log N)$ cryptographic operations. - **Post-Compromise Security (PCS):** Group keys are rotated regularly, ensuring that an compromised historical group key cannot be used to decrypt future group conversations. --- ## 3. Cryptographic Primitives Reference - **Signatures (Identity):** Ed25519 (255-bit curve signatures). - **Key Agreement (Session ratchets):** X25519 (Diffie-Hellman key exchange). - **Symmetric Encryption:** AES-256-GCM or ChaCha20-Poly1305 for authenticated payload encryption. - **Local DB Encryption:** SQLCipher using PBKDF2 key derivation from keys locked inside hardware secure enclaves.