This website uses cookies. By continuing to browse or by clicking Accept you agree to storing the cookies on your device. Otherwise please close the page immediately. Privacy Policy

You are using unsupported web browser, this page cannot work properly! Please use Mozilla Firefox, Google Chrome or Apple Safari.

How Safevia.net works - technical perspective

Encryption & decryption on client side (End-to-End)

The main advantage of Safevia.net is that instead of sending plain text or encrypting text and files on the server, it always encrypts content directly in the web browser on the sender's device. Subsequently, decryption is done in the receiver's web browser. Encryption/decryption key is never sent to the server and only used directly in the web browser.

Security standards

Safevia.net is using the AES-GCM symmetric encryption algorithm with a 256-bit length key. In passwordless mode the key is generated randomly. In password mode the encryption key is derived based on password by PBKDF2 function with SHA-256 hash through 150000 iterations with a 128-bit random salt. These are strong, mature, and proven cryptography standards.

Secrets in the link URL

Secretly generated link (URL) for the receiver contains the following elements:

  • [m] in a Query String - message identifier
  • [s] in a Query String - server and version indicator
  • [k] in a Hash/Anchor part - encryption key (only in passwordless mode)
  • [sc] in a Hash/Anchor part - salt for password check (only in password mode)
  • [sk] in a Hash/Anchor part - salt for deriving encryption key (only in password mode)
  • [u] in a Hash/Anchor part - user token needed to fetch encrypted content
Hash/Anchor part is a part of the URL, which is after # character, that is not sent to the server on the web browser's request. So the encryption/decryption key is never sent to the server and can be considered a secret (from transmission point of view). User token from URL is read by application and sent on encrypted message fetch request to authenticate and authorize the receiver.

Transparent and auditable

Safevia.net focuses primarily on security. We believe that security and transparency should go hand in hand so that every user can verify how this service works. This is why all JavaScript source code files - including parts responsible for encryption and decryption - are fully auditable, which means: no minimization, no obfuscation, easily readable. So anyone familiar with programming can easily verify that:
  • message text and files are not transferred in an unencrypted form to the server
  • data on the server cannot be easily decrypted because the encryption/decryption key is protected
  • way of encryption is valid and secure

No external vendor code

In Safevia.net there's no executable code in the service that cannot be managed by us. In particular, this site doesn't use any external tracking and analysis services or commercial advertisement networks. What's more, for cleanliness and safety, the source code does not have any code dependencies in the form of external libraries.

Protection from bots

In case an indexing bot or preview generating bot would visit URL (because it has been sent through e.g. Gmail or Facebook), it won't see an unencrypted message directly. Button has to be clicked manually or intentionally automated first to run decryption. Each such try to fetch encrypted messaged (even automated) will be logged. What's more, in password-based mode content is fully protected from bots.

You are safe from us and safer from hackers

Without having access to the full link (URL address) to the message, no one from Safevia.net Administrators will be able to read the content. This means it is also much harder for hackers to intercept the content of all the messages. You don't have to trust us, but you can trust the cryptography and source code audit.

Start