Thread: Crypto scheme

    #1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2012
    Posts
    4
    Rep Power
    0

    Crypto scheme


    Hello

    I am developing a live chat where all messages between users should be encrypted, saved on server database, but the server should not be able to decrypt the messages. If I use a public/private key system (with private key for decryption, computed client-side, based on user password, and public key, for message encryption, saved on server database), then everything is ok until the moment when an user changes his password. Then he will have another key (computed upon his new password), therefore he will be unable to decrypt his message archive.

    Can you suggest me a cryptographic scheme that will work in my scenario?

    Regards
  2. #2
  3. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2011
    Posts
    313
    Rep Power
    0
    First, do not involve passwords into encryption process,
    only private keys.

    But if this is a live chat between 3 or more persons
    (say A, B and C), is A allowed to see B vis C posts ?

  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2012
    Posts
    4
    Rep Power
    0
    This will be a two-person chat only. And only those two persons are allowed to view their messages (the server is not allowed to, all messages should arrive encrypted at the server; also all messages are saved encrypted in the database).

    I want to find a solution to generate the keys for every person, and also to be able to read message archive if someone finds one`s key and he needs to change it (the archive will still be in the database, but encrypted with the old key)
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2011
    Posts
    313
    Rep Power
    0
    So it is basically encrypted e-mail.

    Why not to allow the server to act as a "postman",
    sending, receiving and storing encrypted messages ?

    For key generation you should read more info from www.
    For example, PGP description.
  8. #5
  9. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2012
    Posts
    4
    Rep Power
    0
    The problem is that the server should not be allowed to decrypt the messages. The server receives encrypted message from one client, saves it in database and then sends it to othe client as it is.
  10. #6
  11. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2011
    Posts
    313
    Rep Power
    0
    So, you certainly need a kind of a "client program".

    That's my opinion.

    But maybe better wait for other posts.
  12. #7
  13. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Feb 2012
    Posts
    4
    Rep Power
    0
    Also, I have to say that the client is javascript, so the code can be viewed by everyone.
  14. #8
  15. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    May 2007
    Posts
    765
    Rep Power
    928
    PKI & certificates might work for you: Each user generates a public/private key pair and obtains a public key certificate from a mutually trusted third party. They exchange certificates via the server, verify them, and then use these keys to encrypt & sign their messages.

    You're going to need a trusted third party or a secure alternate communications path somewhere if you can't trust your server.

    Of course, not trusting the server makes it kind of pointless in your case. An attacker that compromises it could simply replace the javascript code sent to the clients with his own code that saves a copy of the clear text.
    sub{*{$::{$_}}{CODE}==$_[0]&& print for(%:: )}->(\&Meh);
  16. #9
  17. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,296
    Rep Power
    7170
    Of course, not trusting the server makes it kind of pointless in your case. An attacker that compromises it could simply replace the javascript code sent to the clients with his own code that saves a copy of the clear text.
    Quoted for emphasis because this is an exceedingly important and true point.

    However, that weakness with your implementation aside, the particular security question you pose is not an uncommon one and has standard solutions.

    One such solution is to generate the public and private key for each user entirely randomly and store both on the server. The public key in its plaintext form and the private key in an encrypted form. The private key is encrypted and decrypted client-side using a symmetric cipher, such as AES, with a key derived from the user's password.

    In this situation, a password change is simple: retrieve the encrypted private key from the server, decrypt it using the symmetric key derived from the old password, encrypt it using the symmetric key derived from the new password, then send it back to the server for storage.

    But as OmegaZero stated, not trusting the server is not an option if you use JavaScript.
    PHP FAQ

    Originally Posted by Spad
    Ah USB, the only rectangular connector where you have to make 3 attempts before you get it the right way around

IMN logo majestic logo threadwatch logo seochat tools logo