Critical improvement needed to encryption scheme

[lbdroid]

It looks like you're using a symmetric key encryption with a "global" device key and having optional per-contact keys.

This is a bad approach since;

1. If you are not using a per-contact key, then a single compromised contact will compromise all messages using the global key, which means that authorities may be able to monitor communications with OTHER contacts.
2. Symmetric keys are complicated to convey to a contact in a secure manner, since they have the capacity to decrypt any message encrypted with the same key -- the security of a symmetric key absolutely depends on the security of everyone in possession of the symmetric key, which can't be guaranteed in this application, and the transfer of which cannot be guaranteed to be secure.

Having a global key isn't necessarily a bad thing, but combining it with symmetric key encryption introduced unnecessary danger as described above. Use of public key encryption with a global key is fully secure, and also eliminates all need for per-contact keys since the only way to compromise communications is for the PRIVATE key to be leaked, and only you have control over that.

The public key can be conveyed safely over UNencrypted SMS, through a website, QR-code, etc.

[vivabelarus]

Thanks for the feedback!

My opinion on this problem.

You should not hope for the safety of transferring a public key through unencrypted SMS. The communication operator can intercept such an SMS and replace the public key with his own and gain access to the conversation (man in the middle). In the case of sites, this problem is solved using certificates that confirm the authenticity of encryption keys. But we cannot make certificates for ordinary application users.

In addition, asymmetric encryption causes some problems. Firstly, installing the connection using symmetrical keys is more difficult and requires sending additional messages. Secondly, a message encrypted using asymmetric keys, as a rule, will be more than a message encrypted with ordinary keys. And the size of the message is important for us. We use steaganography to complicate the automatic detection of encrypted messages. The side effect of this is a strong decrease in the transmitted data by one SMS. And we would not want the size of these data to decrease even more due to asymmetric encryption.

Since asymmetric keys still do not solve the problem, we decided that it is better to use symmetrical encryption and exchange encryption keys in a safe way. For example, in a personal meeting or through safe messengers.

I agree with you that the use of the global key is unsafe, since if it is received from one of the interlocutors, it will be possible to decipher any messages. Therefore, I believe that it is better to set the key to each interlocutor separately. Probably, now in the application this is not very conveniently implemented. In the following updates, it is worth emphasizing that it is better to use a separate key for each interlocutor and you do not need to transmit it through unencrypted SMS. And make a key transmission through QR, of course. Perhaps we should completely remove the global key.

It would be interesting for me to continue the discussion. What do you think about what I wrote above?

[lbdroid]

I question whether or not you actually understand how public key encryption works. The WHOLE POINT of it is that it is perfectly safe to transfer a public key IN PUBLIC, which is why its called a PUBLIC key.

[vivabelarus]

Do you understand how a man-in-the-middle attack works? You can read about it on Wikipedia. There is a good example there that shows why the use of public key technology is not enough and additional tools are needed.

[jfmcbrayer]

I know this issue is closed, but I wanted to note that the normal solution to MITM with public-key encryption is to verify your interlocutor's public key's fingerprint over a separate channel. I don't see that as being harder than exchanging symmetric keys.

Also, though, neither this symmetric scheme nor a straightforward public key solution provide forward secrecy, which is considered a must-have these days. It would probably be better to implement OTR or Olm.

[vivabelarus]

Yes, it might make sense. But there are several problems here:

1. SMS is usually much more expensive than Internet traffic. Users may not want the application to send a few more messages for the key exchange. Although these features, of course, could be made optional.
2. Steganography. On the Internet, encryption is ubiquitous today and does not arouse anyone's suspicions. But this does not apply to SMS. Therefore, if the mobile operator can easily understand that users are exchanging encryption keys, then he can transfer this data to the police and the participants in the correspondence will have problems. And if we want the operator not to know that SMS contains encryption keys, then the application should also not be able to find out.

Perhaps the key exchange makes sense not to establish a connection, but to update the session key. Like some kind of forward secrecy. What do you think about this?

[jfmcbrayer]

I am not enough of a cryptography expert to comment sensibly other than recommending well-known protocols. I do know that cryptographic systems are more often broken through weak protocols than through weak cryptographic primitives, so I would not recommend trying to create your own forward secrecy protocol.

I think you probably could still use steganography with OTR, but yes, there is a several message overhead to set up a conversation, and that may not be acceptable for your use case. Protocol reference here: https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html