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
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
