LogoLogo
DownloadsBlock ExplorerSupport
  • πŸ’‘Introduction to Oxen
  • πŸ“Downloads
  • πŸ†˜Support
  • About the Oxen blockchain
    • πŸ—ΊοΈOverview
    • πŸ“ŠToken economics
      • πŸ”₯Token burning
    • πŸ–₯️Oxen Service Nodes
    • πŸ’“Pulse: PoS on Oxen
      • 🀿Pulse: Deep dive
    • πŸ‘οΈBlink: Instant transactions
  • Using the Oxen Blockchain
    • πŸ“Overview
    • πŸ’°Oxen Wallet & Guides
      • Preparing for GUI Wallet setup (Windows)
      • GUI Wallet setup
      • GUI Wallet Quickstart
      • GUI Wallet Staking
      • Oxen Mobile Wallet Quickstart
      • Mobile Wallet Staking Guide
      • Exporting a CSV of your wallet transaction history
      • CLI Wallet setup (macOS)
      • Oxen Ledger Wallet setup: GUI Wallet
      • Oxen Ledger Wallet setup: CLI Wallet
      • CLI Wallet commands
      • Restoring an Oxen CLI Wallet from seed
      • Restoring an Oxen CLI Wallet from keys
    • πŸ–₯️Service Node guides
      • 🏎️Express service node setup guide
      • 🍺Full service node setup guide
      • πŸ’ΈStaking to a shared Oxen Service Node
      • πŸ›‘Service Node deregistration
      • πŸ› οΈService node tools and upkeep
    • ⛴️Migrating to the new Session Network
      • βœ…Migration Checklist
      • ❓Migration FAQ
      • πŸ”—Connecting to an Arbitrum One RPC Endpoint
      • πŸ”€How to set up an oxend L2 proxy
    • πŸ”‘Using Oxen Name System (ONS)
    • πŸ€“Advanced
      • Service node πŸ“ž RPC calls
      • Daemon πŸ“ž RPC calls
      • Wallet πŸ“ž RPC calls
  • Products built on Oxen
    • πŸ”’Session
      • πŸ“šGuides
        • 🐧Installing on Linux (Debian based distros)
        • πŸ—£οΈSession Open Group Server Setup
          • πŸ“—Read Only Room Setup
      • πŸ”€Oxen Name Service for Session
      • πŸ—οΈNetwork infrastructure
      • πŸ“¨Message routing
      • πŸ“ŽAttachments
    • 🌐Lokinet
      • πŸ“šGuides
        • 🐧Installing on Linux (CLI)
        • 🐧Installing on Linux (GUI)
        • 🐧Linux troubleshooting
        • 🍎Installing on macOS
        • πŸͺŸInstalling on Windows
        • 🍎macOS troubleshooting
        • πŸ“žRun a secure Mumble server over Lokinet
      • πŸ‘‹Exit nodes
      • πŸ§‘β€πŸ’»πŸ§‘πŸ’» SNApps
        • πŸš€Accessing SNApps
        • πŸ–₯️Hosting SNApps
        • πŸ—ΊοΈDomain Names For Lokinet (ONS)
        • ⏺️Configuring SRV Records
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
Export as PDF
  1. Products built on Oxen
  2. Session

Attachments

PreviousMessage routingNextLokinet

Last updated 3 years ago

Was this helpful?

Although have the ability to store data on behalf of clients, this responsibility only extends so far. Requiring service nodes to store attachments, which can easily be orders of magnitude larger than messages (and might need to be stored for longer periods of time) would place an undue burden on the service node network.

With this in mind, a logical solution is for Session to interface with an untrusted centralised server that stores data obliviously. As long as the central server cannot know the contents of files, or who is storing and requesting the files, this system does not cause any metadata leakage.

This is achieved by first padding each attachment to fit within a fixed number of constant sizes between 0 and 10 megabytes, then encrypting the attachment with a random symmetric AES key. The sender then uploads the encrypted file using an onion request. In response, the file server provides a link to the piece of content, returned via the onion request path.

Once the sender obtains this link, they then send a message to the recipient via an existing pairwise session. This message contains a link to the content, a hash of the content, and the decryption key. The recipient then uses an onion request to pull the encrypted attachment from the centralised file server and decrypt it locally using the decryption key provided by the sender. The recipient also checks the hash against the attachment, ensuring the file has not been modified in transit.

By default, all Session clients use a Session file server run by the for attachment sending and storage. Since attachments are not considered a core feature of Session, this design is in keeping with Session's design principles. The file server is fully open-source, with setup instructions provided so that users are able to set up their own file server. In an upcoming update users will be able to specify in the Session client which file server they want to use for attachment sending functionality. This is important both for providing users with choice and control, and ensuring the continued usefulness and functionality of Session if the OPTF were no longer able to maintain the default Session file server.

πŸ”’
πŸ“Ž
service nodes
Oxen Privacy Tech Foundation