You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation performs the encryption in the server side. Whereas the server does not store the password, when a new lacrado message is sent, the message itself as well as the password is sent from the client to the server, then the server using that password as key encrypts the message.
The problem with this approach is that if the server gets compromised, then messages can be exposed on submit time or on read time.
The solution would be to perform the encryption in the client side, so the server only receives the encrypted message, and the metadata about the number of times to be seen or the expiration date.
The text was updated successfully, but these errors were encountered:
The current implementation performs the encryption in the server side. Whereas the server does not store the password, when a new lacrado message is sent, the message itself as well as the password is sent from the client to the server, then the server using that password as key encrypts the message.
The problem with this approach is that if the server gets compromised, then messages can be exposed on submit time or on read time.
The solution would be to perform the encryption in the client side, so the server only receives the encrypted message, and the metadata about the number of times to be seen or the expiration date.
The text was updated successfully, but these errors were encountered: