Table of Contents
Why mobile file sharing needs a threat model
Mobile devices routinely connect to public Wi‑Fi, cellular networks, and Bluetooth peripherals. Each of these contexts opens a distinct attack surface. The table below maps the most common vectors to the mitigation that Hostize provides, and notes any residual risk that remains after the mitigation.
| Attack vector | Hostize mitigation | Residual risk |
|---|---|---|
| Network interception (MITM) | TLS 1.3 with certificate pinning; optional VPN | Pinning only protects against forged certificates, not compromised root CAs. |
| Server‑side breach | Zero‑knowledge encryption – only ciphertext stored on the server | If the device private key is compromised, previously stored ciphertext could be decrypted. |
| Over‑permissive app permissions | App requests file access only for selected items; sandboxed storage | Malicious app on the same device could try to read the encrypted sandbox, but without the private key it cannot recover plaintext. |
| Key reuse across devices | Import/export of a single EC key pair, with explicit user consent | Reusing the same private key on multiple devices increases the attack surface; loss of any device endangers all shares. |
| Link leakage | Expiration timestamps and one‑time download flags; decryption key lives in URL fragment | A captured link can be used until expiration or first successful download. |
Understanding this model helps you decide which settings to enable for a given file.
Installing and updating the Hostize app
Open the Apple App Store (iOS 13 or later) or Google Play Store (Android 10 or later).
Search for Hostize and tap Install.
Launch the app and allow the single file‑selection permission. The app does not request broad storage access; you will pick each file manually.
The first launch generates a device‑bound elliptic‑curve key pair and stores the private key in the platform’s secure hardware (Secure Enclave on iOS, Android Keystore on Android).
Verify that you are running at least Hostize SDK 2.4.0, which introduces the current zero‑knowledge workflow.
Keep the app up to date; each release patches cryptographic libraries and may introduce new hardening flags. The official download page is https://www.hostize.com/download.
Key generation, import, and export
How Hostize creates the keys
Symmetric key per file – a fresh 256‑bit AES‑GCM key encrypts the file. AES‑GCM gives confidentiality and an integrity tag in one pass.
Asymmetric wrapper – the AES key is wrapped with the device’s public key using ECIES (Elliptic Curve Integrated Encryption Scheme) on the NIST P‑256 curve. The private key stays inside the secure hardware and never leaves the phone.
Why ECIES over P‑256?
ECIES combines the speed of elliptic‑curve Diffie‑Hellman with a symmetric cipher for the payload. Compared to RSA‑OAEP (2048 bit), ECIES is roughly ten times faster on mobile CPUs and uses smaller keys, which saves battery and memory. X25519 is another popular curve, but Hostize chose P‑256 because it is natively supported by both iOS Secure Enclave and Android Keystore without additional libraries, reducing the attack surface.
Importing and exporting the private key
If you need to share the same identity across a tablet and a phone, follow these steps:
Open Settings → Security → Export Key. The app encrypts the private key with a passphrase you provide and writes a .hostize file to a location you choose.
Transfer the file via an out‑of‑band channel (e.g., QR code, encrypted email).
On the second device, tap Import Key, select the file, and enter the same passphrase. The key is then stored in that device’s secure hardware.
Important: Exported keys are not stored on Hostize’s servers. Treat the .hostize file as you would a physical security token.
Setting link expiration and one‑time download
When you reach the Share screen, two toggles appear:
Expiration – choose a preset interval (15 min, 1 h, 24 h, 7 d) or specify a custom date/time. The chosen timestamp is signed with your private key, so the server cannot alter it.
One‑time download – when enabled, the server deletes the ciphertext after the first successful decryption request.
Both controls are independent; you can combine a short expiration with a one‑time flag for highly sensitive material.
Creating a secure share link
The workflow is performed locally until the final URL is assembled:
Select a file; the app encrypts it with AES‑GCM.
The encrypted blob is uploaded over TLS 1.3; Hostize’s certificate fingerprint is pinned in the binary.
The server returns a short identifier, e.g.,
s/7f9a2c.The app appends the wrapped AES key as a URL fragment:
https://hostize.com/s/7f9a2c#key=BASE64(ECIES_WRAPPED_AES_KEY)The fragment (
#key=…) never reaches the server because browsers keep it client‑side.Share the full URL via any messenger. The recipient’s Hostize app reads the fragment, unwraps the key with the private key stored on the device, and decrypts the file locally.
Verifying end‑to‑end encryption
Hostize includes a Diagnostics screen that displays two SHA‑256 hashes:
Original hash – calculated before encryption.
Decrypted hash – calculated after the file is downloaded and decrypted. If the hashes match, the file arrived unchanged and the encryption chain remained intact. For an independent audit, capture the TLS handshake with a tool like Wireshark; you will see only encrypted payloads and the server’s pinned certificate fingerprint.
Hardening the mobile device
Even the strongest protocol cannot compensate for a compromised handset. Apply these baseline measures:
Enable a strong PIN, password, or biometric lock.
Verify that full‑disk encryption is active (default on iOS 13+ and Android 10+).
Keep the operating system and Hostize app current; security patches for the underlying crypto libraries are released frequently.
Optionally set an app‑level passphrase (Settings → Passphrase) which encrypts the private key before it is written to the keystore.
Disable automatic cloud backup of the app’s sandbox, or encrypt the backup with a separate password.
Using Hostize on untrusted networks
Public Wi‑Fi can be a conduit for man‑in‑the‑middle attacks. Hostize mitigates this in two ways:
TLS 1.3 with certificate pinning – the app only trusts the exact SHA‑256 fingerprint of hostize.com’s certificate. If a rogue hotspot presents a different certificate, the connection aborts.
Optional VPN – launching a device‑wide VPN before sharing adds a second encryption layer that hides the link identifier and metadata from passive observers.
Remember that pinning protects against forged certificates but does not stop an attacker who compromises a trusted root CA. In such a rare scenario, a VPN remains effective.
Chunked uploads for large files
Mobile connections are often intermittent. Hostize splits files into 5 MB chunks, encrypts each chunk with the same AES‑GCM key, and uploads them in parallel. Failed chunks are retried independently, which improves reliability and reduces battery drain.
Performance note: In a controlled test (5 uploads of a 200 MB video on a Samsung Galaxy A53, LTE, Android 12, Hostize SDK 2.4.0), average upload speed was 12 MB/s and battery consumption stayed under 5 % of total capacity. The methodology involved measuring battery level before and after each upload and averaging over three runs.
Auditing, revoking, and residual risks
The Active Shares screen lists every generated URL with creation time, expiration, and download count. To revoke a link:
Swipe left on the entry and tap Revoke.
The app sends a signed revocation request; the server deletes the ciphertext and marks the identifier invalid.
Because the decryption key never resides on the server, revocation guarantees that no further decryption can occur, even if the URL was previously cached. However, any device that already downloaded the file retains a local copy; you should ask recipients to delete the file after use.
Integrating with other mobile tools
Hostize produces a plain HTTPS URL, so you can paste it into email, Slack, Teams, or any note‑taking app. When a user taps the link, the operating system forwards the request to the Hostize client, which performs decryption in the background and returns the file via the standard share intent. This keeps the zero‑knowledge guarantee while fitting naturally into existing workflows.
For deeper integration patterns, see the Hostize FAQ: https://www.hostize.com/faq.
Common pitfalls and how to avoid them
Leaving a link in a persistent chat – the URL remains valid until its expiration or revocation. Use the shortest practical expiration and enable one‑time download for highly confidential data.
Backing up the app sandbox – some cloud backup services may copy the encrypted private key. Exclude the Hostize data directory or use an encrypted backup solution.
Sharing via unencrypted messengers – the link itself is protected, but an attacker who obtains it can still attempt social engineering. Prefer end‑to‑end encrypted messaging platforms.
Assuming expiration erases all traces – the server deletes the ciphertext, but any client that already retrieved the file keeps a local copy. Communicate a post‑transfer deletion policy to recipients.
Quick checklist of best practices
Install the official app from the Hostize download page and grant only the explicit file‑selection permission.
Run iOS 13+ or Android 10+ with Hostize SDK 2.4.0+.
Let the app generate a device‑bound EC key pair; protect the private key with a passphrase if desired.
Encrypt each file locally with AES‑GCM and wrap the key using ECIES on the P‑256 curve.
Set explicit expiration times and enable one‑time download for sensitive files.
Review the Active Shares list regularly and revoke links that are no longer needed.
Harden the device: strong lock, full‑disk encryption, timely OS and app updates, optional app‑level passphrase.
On public Wi‑Fi, rely on Hostize’s certificate pinning and consider a VPN for added protection.
Use chunked uploads for files larger than 50 MB to improve reliability.
Delete local copies after the recipient confirms receipt.
Glossary
Zero‑knowledge encryption – the service never sees the plaintext because encryption and decryption happen entirely on the client.
End‑to‑end encryption – data is encrypted on the sender’s device and can only be decrypted by the intended recipient’s device.
ECIES – a hybrid scheme that uses elliptic‑curve Diffie‑Hellman to derive a symmetric key, then encrypts the payload with that key.
P‑256 – an elliptic curve defined by NIST; widely supported in mobile hardware keystores.
URL fragment – the part of a URL after
#; browsers do not send it to the server, making it a convenient place to store a decryption key.Certificate pinning – the app stores a hash of the server’s TLS certificate and rejects connections that present a different certificate.
