1
$\begingroup$

I am a beginner in cryptography and I am interested for several weeks on this for my chat application.

Basically, it is a centralized model. All messages are stored and potentially visible by authorities or server administrators.

Here the global functioning of the chat :

  • Each person may register with a nickname, add another person in his contacts through this nickname. We can create multiple accounts with different usernames so.

  • We can talk through messages with a contact, just one. No group conversation. The contact must be connected so we can instantly talk.

  • If the contact is offline and that sends a message, it will see when its connecting (the message are stored on the server)

For this chat to be totally secure I want to ensure that:

  • Only that we talk contact is able to decrypt messages intended for it
  • It is sure to talk to the right person
  • That no one can change the message during transit
  • Even if stolen private key to anyone not be able to decrypt old messages

For doing this here is what I thought :

Overall :

The first time when launching application, you choose a keychain password. This password encrypt all settings/data and all saved account with AES-256.

When you launching application, you have to type this password to unlock all remind account and all settings. The password is saved in RAM as globalPassword

The first time when logging to your account you generate a PGP keypair. The passphrase used is SHA-1 hash of globalPassword

The private key are stored securely (this is managed by GNUPG) and in application database we store the fingerprint of private key and the username of the account.

The public key are sended to public keyserv and the fingerprint of the key with username are stored in application database.

If you restart the program and you are connecting to an account that already has a fingerprint with that user name in the database then no key generation takes place.

For live message :

Imagine that we are Bob and that we want to talk to Alice. We click on "start a secure conversation". Here are listed exchanges (all these exchanges are sent as message so as stored on the server) :

Bob : notify Alice I want to start secured chat

ex : start_encrypted_chat

Alice : notify Bob she can't start secured chat

ex : accept_encrypted_chat

If both are able to start a secure chat, a common secret is generated and shared via Diffie Hellman who now used to encrypt all communications with AES-256.

Bob : sending the fingerprint of his pub key

ex : AES-256(dhSecret, 0xA1C4AFB9DE762368)

3 cases for the processus of key pub verification :

A) If Alice don't have any fingerprint of pub key for the username of Bob in his database, an alert is showed in the screen of Alice asking he if she is sure that it is indeed Bob behind the computer and if she wants to save the public key sent by Bob like Bob username. So if Alice accept all is well.

B) So, if Alice have already in his application database the fingerprint of Bob public key and the new pub key sended by Bob is the same all is well.

C) So, if Alice have already in his application database the fingerprint of Bob public key and the new pub key sended by Bob is not the same of the database, an alert if showed in the Alice screen saying it's probably no Bob behind the keyboard because the public key has changed, you have to trust the new pub key of Bob. Alice call Bob and answer if he has change computer, Bob say yes, Alice trust the new pub key all is well.

Alice : sending the fingerprint of his pub key

ex : AES-256(dhSecret, 0xA1C4AFB9DE762368)

Here the same process of key pub verification take place for the pub key of Alice.

Bob : encrypt random hash challenge1 with pub key of alice and send the cipher to Alice

Alice : send decrypted random hash challenge1

If Alice decrypted random hash don't match with the challenge1 generated by Bob the security is compromised. The session is canceled.

Bob : sending confirmation of the completion of challenge1

Alice : encrypt random hash challenge2 with pub key of bob and send the cipher to Bob

Bob : send decrypted random hash challenge2

If Bob decrypted random hash don't match with the challenge2 generated by Alice the security is compromised. The session is canceled.

Alice : sending confirmation of the completion of challenge2

From here, Bob's public key is verified and that of Alice too. We are sure to talk to the right person: Authentication is assured.

Bob : send "How are you" to Alice : the message are encrypted with dhSecret and the cipher are encrypted with Alice PGP pub key.

Alice can decrypt the cipher of this message with his PGP private key so the cipher with dhSecret

Alice : send "Fine" to Bob : the message are encrypted with dhSecret and the cipher are encrypted with Bob PGP pub key.

Bob can decrypt the cipher of this message with his PGP private key so the cipher with dhSecret

If no message is sent after 30 minutes, or a person ends the conversation the dhSecret are deleted from the RAM if I want to talk again with Alice I have to start over the begin.

What do you think for this protocol in the live chat? Thank you in advance for your advice, I'm just a neophyt un cryptography.

PS: Sorry for my bad english, I using some translators.

$\endgroup$

closed as off-topic by e-sushi Dec 7 '17 at 7:14

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    $\begingroup$ You want to authenticate the key exchange, not the messages themselves with the private key. Note that AES-256 is not a semantically secure encryption scheme; AES-256 is a block cipher, which can be used as building block to create a semantically secure encryption scheme. You need a protocol and mode of operation as well. $\endgroup$ – Maarten Bodewes Oct 29 '15 at 0:32
  • 1
    $\begingroup$ Oh, and you need to use some sort of KDF scheme to derive keys from the dhSecret (separate keys for A & B at the minimum). $\endgroup$ – Maarten Bodewes Oct 29 '15 at 7:39
  • 1
    $\begingroup$ I'd suggest using OTR / Axolotl instead of some home-brew protocol to get more trust. $\endgroup$ – SEJPM Oct 29 '15 at 12:35