If it’s with asymmetric encryption, wouldn’t it be possible for the report button to generate a key based on their private key which can only be used to decrypt the given message?
Sounds like you know more about encryption than I do, I would hope they can do that but I still think a full off switch for users would be wise though.
Yeah, end to end encryption means its not possible for someone to intercept the message between person A and person B. Nothing stops person B then forwarding the message to person C to report it.
Yeah as long as theres an (practically) unfalsifiable way to forward the message that sounds very useful, which sounds like there is based on the response to my first comment.
Been forever since I did any work with cryptography, but if my memory is correct:
Alice needs Bob’s public key to verify a signed message from Bob haven’t been altered;
Bob needs Alice’s public key to encrypt a message that can only be decrypted by Alice;
If Bob sends Alice a message encrypted with Alice’s public key, signed with Bob’s private key, containing “Hello, how are you?” ; this message could be verified as authentic by Charlie using Bob’s public key but Charlie cannot see the contents of the message as Charlie does not have Alice’s private key.
Without Alice disclosing their private key, how can Charlie review the content of a reported message from Alice claiming Bob sent them something inappropriate?
I.e. how can Charlie be certain if Alice claims Bob sent “cats are evil” when Charlie cannot decrypt the original message, only verify the original message have not been altered via Bob’s public key.
It’s been a while since I’ve had to touch it too. But couldn’t Alice provide Charlie with both the plain text and her public key. Charlie could then encrypt the text and see it came out the same as blob Bob sent Alice?
I think this might work, I haven’t done it for too long to know for certain if two same plain text encrypted with two same public key would yield two identical encrypted blobs.
I’ve self replied another possible implementation, that I’m pretty proud of figuring out literally 1AM. If you have time, please do give it a glance and see if you can spot any weakness.
Aha! Something just clicked — been thinking continuously since before the original reply. The answer is … more signing and maybe even more keys!
A message would be signed multiple times.
If Bob wants to send Alice “Hello, how are you?” the plain text would be signed with Bob’s general private key that could be verified with Bob’s general public key. This would allow Alice to forward this message to anyone while they could still verify it did indeed came from Bob.
The plain text and signature is then encrypted with one of Alice’s public keys, so only Alice could decrypt it to see the message and signature. This may be a thread specific key pair for Alice so they’re not re-using same keys between different threads.
The encrypted message is then again signed by Bob, using one of Bob’s private key, so that Alice can know the encrypted message has not been altered. This here could also be the thread specific key as noted above.
If Alice were to report Bob, Alice will need to include both the plaintext and the internal signature. This way the internally signed message could be reviewed if the plaintext and signature were forwarded to moderation for review by Charlie (just need to verify the signature against plaintext with Bob’s public key), while the exchange should be secure to only Alice and Bob.
Or just send them the message in plain text, since you’re showing it to somebody else anyway.
But I think the issue is there’s no way for your instance to stop you getting the spam as they’ve no idea what it is until you unlock it.
I guess the best they could do is block messages from a certain user/instance but since you can generate as many accounts as you want, it’s hard to tell how effective that could be.
If you send them the message in plain text they have no way of verifying you aren’t just making it up to get someone you don’t like banned. Keeping it encrypted means they know the sender wrote it.
That’s a good idea. Send message > Message signed and sent > Receiver opens message, signature bits are hidden, but clicking report sends plaintext with signature included. Only ends up in report queue if signature is valid.
If it’s with asymmetric encryption, wouldn’t it be possible for the report button to generate a key based on their private key which can only be used to decrypt the given message?
Sounds like you know more about encryption than I do, I would hope they can do that but I still think a full off switch for users would be wise though.
Yeah, end to end encryption means its not possible for someone to intercept the message between person A and person B. Nothing stops person B then forwarding the message to person C to report it.
Yeah as long as theres an (practically) unfalsifiable way to forward the message that sounds very useful, which sounds like there is based on the response to my first comment.
Typically end to end encryption includes digital signing of the message so you can verify who the sender was.
Been forever since I did any work with cryptography, but if my memory is correct:
Alice needs Bob’s public key to verify a signed message from Bob haven’t been altered;
Bob needs Alice’s public key to encrypt a message that can only be decrypted by Alice;
If Bob sends Alice a message encrypted with Alice’s public key, signed with Bob’s private key, containing “Hello, how are you?” ; this message could be verified as authentic by Charlie using Bob’s public key but Charlie cannot see the contents of the message as Charlie does not have Alice’s private key.
Without Alice disclosing their private key, how can Charlie review the content of a reported message from Alice claiming Bob sent them something inappropriate?
I.e. how can Charlie be certain if Alice claims Bob sent “cats are evil” when Charlie cannot decrypt the original message, only verify the original message have not been altered via Bob’s public key.
It’s been a while since I’ve had to touch it too. But couldn’t Alice provide Charlie with both the plain text and her public key. Charlie could then encrypt the text and see it came out the same as blob Bob sent Alice?
I think this might work, I haven’t done it for too long to know for certain if two same plain text encrypted with two same public key would yield two identical encrypted blobs.
I’ve self replied another possible implementation, that I’m pretty proud of figuring out literally 1AM. If you have time, please do give it a glance and see if you can spot any weakness.
Aha! Something just clicked — been thinking continuously since before the original reply. The answer is … more signing and maybe even more keys!
A message would be signed multiple times.
If Bob wants to send Alice “Hello, how are you?” the plain text would be signed with Bob’s general private key that could be verified with Bob’s general public key. This would allow Alice to forward this message to anyone while they could still verify it did indeed came from Bob.
The plain text and signature is then encrypted with one of Alice’s public keys, so only Alice could decrypt it to see the message and signature. This may be a thread specific key pair for Alice so they’re not re-using same keys between different threads.
The encrypted message is then again signed by Bob, using one of Bob’s private key, so that Alice can know the encrypted message has not been altered. This here could also be the thread specific key as noted above.
If Alice were to report Bob, Alice will need to include both the plaintext and the internal signature. This way the internally signed message could be reviewed if the plaintext and signature were forwarded to moderation for review by Charlie (just need to verify the signature against plaintext with Bob’s public key), while the exchange should be secure to only Alice and Bob.
Et voila!
Or just send them the message in plain text, since you’re showing it to somebody else anyway.
But I think the issue is there’s no way for your instance to stop you getting the spam as they’ve no idea what it is until you unlock it.
I guess the best they could do is block messages from a certain user/instance but since you can generate as many accounts as you want, it’s hard to tell how effective that could be.
If you send them the message in plain text they have no way of verifying you aren’t just making it up to get someone you don’t like banned. Keeping it encrypted means they know the sender wrote it.
Only if the sender signed it. I presume the system does that anyway so you can be sure who sent something.
It could be sent plaintext as long as the senders signature was intact.
That’s a good idea. Send message > Message signed and sent > Receiver opens message, signature bits are hidden, but clicking report sends plaintext with signature included. Only ends up in report queue if signature is valid.