Our goal is to be able to demo QSS with interested users at a conference, and for people to be able to try Quiet with QSS, but we decided we can't use QSS publicly if QSS data is shared with our server in plaintext.
We can encrypt it using symmetric encryption (AES-256), which adds 32 (more?) characters to the invite link. This secret is never shared with the server, and should be used for encrypting and decrypting data whenever sending to or receiving from the server.
@siepra are there any nuances to how we are using Node's crypto module on Android and iOS?
Our goal is to be able to demo QSS with interested users at a conference, and for people to be able to try Quiet with QSS, but we decided we can't use QSS publicly if QSS data is shared with our server in plaintext.
We can encrypt it using symmetric encryption (AES-256), which adds 32 (more?) characters to the invite link. This secret is never shared with the server, and should be used for encrypting and decrypting data whenever sending to or receiving from the server.
@siepra are there any nuances to how we are using Node's
cryptomodule on Android and iOS?