0

I have a chat application built in Java. The chat app stores a log of the user Jimmy's chats locally on his machine.

I want this chat log to be encrypted so if someone uses the computer (authorized or unauthorized) he cannot simply read all of Jimmy's chats. I would like Jimmy's chats to only be readable when Jimmy is logged in. As soon as he logs out, the chats should be encrypted and unreadable.

Any ideas on how this sort of scheme could be implemented?

Curious1
  • 113
  • 1
  • 1
  • 4

2 Answers2

2

Ok, I'm no expert in this. Maybe others can add in. But from your description, this is what I can come up with.

  1. client logs in.
  2. server issues a key, K.
  3. client keeps K in memory to encrypt log on disk as well as decrypt any log read back in memory for viewing.
  4. upon client attempt to log out, or disconnection, key K is wipe from memory.

That way, the client would have no key to decrypt anything in the absence of active session, such as accidental disconnection in addition to logout. Here, I'm assuming the key K is being sent securely across using something like TLS.

However, encryption scheme is always hard to get right. Let see what others say.

xyz
  • 377
  • 2
  • 8
  • But if an attacker gets hold of the key he will be able to access the logs at a later time, even when the user is not logged in, won't he? – Curious1 Dec 08 '15 at 04:42
  • If that is of concern, then you can also recycle the encryption from time to time. By that I mean while the client is connected to an active session, the server can issue a new key together with an old key for the client to decrypt the existing log and re-encrypt it using the new key. I didn't add this in the original answer to avoid complicating the scheme. – xyz Dec 08 '15 at 04:55
  • Furthermore, this risk of attacker getting hold of the key is hard to be eliminated to some extend. For example, one can also argue that an attacker can record all the traffic during the session and later get hold of the key to decrypt all the previous messages. Your concern about the decryption of the logs at a later time is no difference from a typical encrypted hard disk being stolen. If it is really a concern for your app, then you might want to revise the need to keep the log on the client app. – xyz Dec 08 '15 at 04:57
2
Solution 1.
don't keep logs.
this is the only 100% secure option.

    Problems with this approach 
    1. there are no logs

Solution 2.
Encrypt the data with the user's password as he logs in to the application, 
it decrypts the chat logs and on logout it encrypts and stores the logs again this requires nothing to be passed to the server. 

Problems with this approach 
    1. If the user's password is lost the logs will be unrecoverable.
    2. If the attacker is competent in cryptography he could decrypt the file.
    3. this will not stop the user from copying the data while it is decrypted. 

Solution 3. 
Assuming a field in the database can be created using solution 2 but also have it create a random string, 
then transmit the string to the server on logout encrypt the user's password with the random string, 
then use the encrypted password to encrypt the logs and clear the random string after transmission 
on login read the string decrypts the file generates a new key and overwrite the string on the database.

Problems with this approach 
    1. If the user's password is lost the logs will be unrecoverable.
    2. If the attacker is competent in cryptography and has the resources he could decrypt the file.
    3. this will not stop the user from copying the data while it is decrypted.


Storing something locally, you don't want someone to have access to at some point is inherently risky.

At the end of the day the decision on what solution you want to use comes down to the value of the data 
that is being transmitted someone isn't going to spend time or money trying to decrypt something worth 
only $10 but if its worth say $10,000+ it may be worthwhile and if thats the case investing in storage 
may be the best option.
  • If you use the user's password as a key, you'll lose access if the user forgets their password. – Neil Smithline Dec 08 '15 at 05:29
  • +1 for suggesting storing the logs on the server – Neil Smithline Dec 08 '15 at 05:30
  • thanks Neil that's a good point i had not considered i have updated by answer to reflect the assumption the password is recoverable. – Dillon Wright Dec 08 '15 at 05:54
  • Or you can just lose access. Depending on the use case, that may be fine. It's important to mention tho. – Neil Smithline Dec 08 '15 at 05:58
  • @DillonCurrie storing the logs on the server is not an option. The server doesn't have any storage, it just contains account info and is the intermediary between users – Curious1 Dec 08 '15 at 06:34
  • @Curious1 In that case what is the reason you want the logs encrypted for the users peace of mind / safety or to protect the information from a disgruntled employee or hacker? – Dillon Wright Dec 08 '15 at 07:48
  • @DillonCurrie to protect against someone (perhaps disgruntled or gruntled) from trying to copy the file and reading it – Curious1 Dec 08 '15 at 15:46
  • i also had an idea about using the users local machine as a storage server then streaming the data back to the server after the server has decrypted the info streams it back. kind of like a peer to peer model but its actually more (Client Server)(Server Client) however would allow for an additional layer of security as the key is never transmitted to the client however it would be technically complex and require some server resources depending on the size of the logs but could be worth thinking about – Dillon Wright Dec 09 '15 at 03:39