0

The public key and private key pairs are created on the client side via a java script algorithm and the public key is then transferred over to the Server.

A copy of the persons private key was stored on the users computer in the form of a java script variable.

When User A sends a message to User B

The server encrypts the message with User B's public key.

User B picks up the message and decrypts (algorithm written in java script) it with User B's private key which is private and kept in a java script variable.

At no point in the time the User B's private key is disclosed over the network what so ever.

Would that be secure???

Rndm
  • 6,710
  • 7
  • 39
  • 58
Ere
  • 3
  • 2
  • if any of the below answers were useful to you, please mark as accepted so people wont we spending time on this question any longer. – techfoobar Jul 20 '12 at 19:07
  • Before anyone can answer the question "is this secure", you need to explain what your threat model is. That is, who are your attackers, what are their goals, and what resources do they have? – Nick Johnson Jul 23 '12 at 05:08

3 Answers3

2

'public' and 'private' are just names given to the two keys. It doesn't matter WHICH of the two keys is public and which is private, as long as you never ever mix up the usage. Once both keys are available to someone at the same time, the security of the messaging system is utterly destroyed.

Technically, since you say the keys are stored in javascript variables, you're implying that the variables were sent IN THE CLEAR embedded in some browser-based html/javascript. That further implies that there's no security - since both keys are exposed to the network.

Marc B
  • 356,200
  • 43
  • 426
  • 500
  • Re: "since you say the keys are stored in javascript variables, you're implying that the variables were sent IN THE CLEAR embedded in some browser-based html/javascript": That's not true. The OP explicitly stated that "the public key and private key pairs are created on the client side via a java script algorithm and the public key is then transferred over to the Server." – ruakh Jul 19 '12 at 17:39
  • 1
    "'public' and 'private' are just names given to the two keys. It doesn't matter WHICH of the two keys is public and which is private" - this is a generalization, and as such not always true. Some PK algorithms are symmetric in this fashion, but others are not. – Nick Johnson Jul 23 '12 at 05:07
1

To decide if something is "secure", you have to know what the security requirements are. Your case satisfies a few likely requirements, but there are several likely requirements that it does not satisfy. For example:

  • A plaintext copy of the message is apparently transmitted over the network from User A to the server, so anyone can eavesdrop on it at that point. (This is likely to be a serious problem.)
  • You don't explain how the public key is transmitted to the server. If it's not transmitted in an authenticated fashion, then a man-in-the-middle can generate his own public-private key pair, and give his public-key to the server. (This could be a serious problem.)
  • User B cannot verify the authenticity of the message (s)he receives. The message may have come from the server (and ultimately from User A), or it may have come from anyone else with a copy of the public key. (This may or may not be a serious problem, depending on the application.)

So overall, I would not consider this design to be "secure".

ruakh
  • 175,680
  • 26
  • 273
  • 307
0

It wouldn't be too secure since:

  • The private key of any user (say user B) can be leaked out of your app via injected JS code, or a bad browser addon
  • Once this is done, any one who gets access to any of the messages directed at User B, will be able to decrypt it and make sense of it
  • Of course the above wont happen if you are the only one using the app - since you'll likely have other users with different browser setups/addons/browsing-behaviors etc, it is entirely possible
  • When user A tries to send something to user B, you said the server will encrypt the message using user B's public key - Now, this request made via JS can be interpreted by a middle man. Once done, this middle man can initiate any request to any user by manipulating the sender, referrer etc. This can lead to impersonation and so..
  • You also mentioned that after generation, you intend to send the public key over to the server. This call made from JS can easily be interpreted, which means the public key can be leaked.
techfoobar
  • 65,616
  • 14
  • 114
  • 135