2

In the process of designing a web app that handles public/private key pairs - a Bitcoin web app, specifically - I've had a lot of thought on how to securely handle the storage of the private key, since, using a banking analogy, if someone has access to a user's Bitcoin private key, they have access to all of that user's Bitcoins.

In all scenarios the private key is going to be encrypted in a database that's as secure as possible - no direct Internet access, explicit read/write privileges, etc - but the part that I'm trying to determine and figure out the best solution to is the private key deception. I can do it either on the client side, i.e. in the user's browser, or on the server side.

If I do it in the server side, I could ensure that it's generated and encrypted cryptographically soundly, but if a malicious person gets access to the server, that malicious person will be able to access any decrypted private keys in memory. I could send it to the browser to hold in its storage but then that can raise problems of man-in-the-middle attacks being able to read the private key in transit. All of the decryption/encryption of the private key would be done on the server, including when the private key is first generated.

If I do it client side, I wouldn't have to worry about a malicious person getting the decrypted private key from my server as it would be decrypted in the browser, but since Javascript cryptography isn't as strong as other methods, the encrypted private keys may not be as secure in storage and may be more easily compromised in the case of data theft.

I was originally leaning towards doing the encryption/decryption and key-pair generation in the client side, but now I'm not so sure and to me it seems like they both have valid concerns. Considering the state of the modern browser and its advancements in Javascript cryptography, are the benefits/risks of encryption/decryption in the browser better than the benefits/risks of doing it on the server? Note for this scenario please only consider that the private key would only either reside on the server in memory, or in the browser in memory/localStorage.

Improve this question
2
  • Reading your questions on the 'private' keys sounds confusing. You mentioned public / private keys pair. And then you're talking about private key on the client's browser. Sounds like you are not using the perks of public & private keys. From what I know about asymmetric encryption I thought the 2 different keys should be stored in different entity? So in this case the public key should be client browser holding it, and private key should be server storing. The hacker would require to get 2 different keys to get the data. So if either key is stolen, it would be insufficient.
    – Sky
    May 26, 2014 at 2:43
  • I mention public/private key pairs but essentially I'm only worried about the private key in this scenario. The public key is, as it says, public, and in Bitcoin, the hash of the public key is someone's address, so it's basically insecure by nature.
    – josh
    May 26, 2014 at 2:50

1 Answer 1

Reset to default
2

There are no particular limitations on the security of cryptography in JavaScript; a JavaScript implementation is likely to be slower than a native code implementation, but it will almost certainly still be fast enough for your purposes. However, the real issue is that regardless of whether the cryptography happens on the server or on the client, the users still have to trust you, given that web apps are particularly prone to tampering and do not allow for easy user verification of the source code. Therefore, a web app for managing bitcoin wallets is simply a bad idea. Any user of your website would have to trust you, and all of the certificate authorities trusted by their browsers, with their bitcoins. Given that bitcoin banks have a track record of losing/stealing their users' bitcoins, users are unlikely to trust your website.

See also "Javascript Cryptography Considered Harmful": http://matasano.com/articles/javascript-cryptography/

Improve this answer
2
  • The page you linked to does mention some limitations of cryptography in JavaScript, including the lack of secure erase which implies that his private key might be more easily stolen as it could linger in memory after being used.
    – user2313067
    May 28, 2014 at 10:43
  • @user2313067 That is true, and applies to any private data (such as a password) in a browser.
    – jbms
    May 28, 2014 at 16:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .