Review Of The Drop Message Documentation

Qabel / qabel.github.io

:octocat: The Qabel documentation repository. The technical stuff can be found at our github.io page.

https://qabel.github.io

Other

2 stars 10 forks source link

Review Of The Drop Message Documentation #9

Closed ghost closed 10 years ago

ghost commented 10 years ago

Hi @Gottox and @thechauffeur! And also the rest!

Can you review this document. Is that a solution we can live with it https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Drop

CU k-c13

cburkert commented 10 years ago

But how do we know which public key we have to use to check the signature?

Edit: Thus it cannot verify the "integrity" before decrypting the AES key and decrypting the actual message (which eventually contains the sender id).

cburkert commented 10 years ago

I wrote a possible illustration of the transport message format. https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Drop#transport-format I know the table is ugly. It's the best I could think of in markdown...

L-Henke commented 10 years ago

The header is currently just a proposal. We have to discuss this on monday.

On 8. August 2014 16:20:15 MESZ, Christian Burkert notifications@github.com wrote:

I wrote a possible illustration of the transport message format. https://github.com/Qabel/intern-doc/wiki/Qabel-Client-Drop#transport-format I know the table is ugly. It's the best I could think of in markdown...

Reply to this email directly or view it on GitHub: https://github.com/Qabel/intern-doc/issues/9#issuecomment-51608088

L-Henke commented 10 years ago

Encrypt ciphertext: Pro:

Sender can be identified before decrypting ciphertext. (We don't have to handle data from unknown senders)

Con:

Everyone could have signed the ciphertext without knowing its content. (Doesn't totally match our case, since we also have the sender ID in the plaintext. An attacker cannot modify the ciphertext, so we have a "lite" signature in the plaintext and a full signature of the ciphertext). Of course signer of the ciphertext has to be compared with the sender ID from the JSON)

Encrypt plaintext: Pro:

Only the recipient can decrypt the ciphertext and read the signer of the message.

Cons:

Every ciphertext has to be decrypted before further processing. (Might trigger bugs in utilized libraries)

We currently tend to sign the ciphertext. But changes might occur after further discussion.