4

I have a few columns in the database which should be encrypted. I'm wondering if the way I chose to make this system work is ok, and I'm looking forward to hear some opinions:

I chose RSA algorithm (with phpseclib). The data I need encrypted will be entered by users, so the private key needed for encrypting it will be on the server, and the data will be automatically encrypted once it's entered. Since there's only one person who should see this data, I decided to keep private key on his computer and make separate AJAX calls which will decrypt the data using that key once the admin page shows. What do you think about this way? Implementation is not the problem, I'm only asking what you think about the whole idea

Improve this question
3
  • 2
    If I recall correctly, a general rule of thumb in cryptography is that inventing your own method is almost never a good idea - is there a reason for not using HTTPS?
    – pimvdb
    Nov 6, 2011 at 18:19
  • I'm using HTTPS, but that's not the point. I'm doing all this to secure the data in the database. I don't want both keys on the same server as the database. I believe the way I described insures that the only way to get to the data is to hack both the server and admin's personal computer
    – marlek
    Nov 6, 2011 at 18:26
  • 1
    Actually, implementation is a problem, or rather, the problem: in-browser JS is completely unsuitable for any sort of crypto, what with untrustable environment (window.prompt=new Function()...), lack of safe storage (private key goes WHERE?!? Surely not into localStorage...), etc. etc.
    – Piskvor left the building
    Nov 7, 2011 at 10:46

3 Answers 3

Reset to default
2

will be entered by users, so the private key needed for encrypting it will be on the server

This doesn't make any sense. Surely you mean the data is encrypted using the public key (and decrypted using the private key). Assuming this is the case:

Implementation is not the problem

Yes it is. If the person with the private key is accessing the data via AJAX, that rather implies that it will be decoded by javascript - so you need to address the problem of how to get the private key into the sandbox.

Improve this answer
2
  • It could also be that the private key is transmitted with AJAX (via SSL for confidentiality) to server that does the decryption and discards the key later on.
    – Krzysztof Kotowicz
    Nov 7, 2011 at 13:12
  • That doesn't solve the same origin policy of the sandbox.
    – symcbean
    Nov 7, 2011 at 16:07
2

The problem with storing the key client-side (and accessible via Javascript) is that a single XSS flaw can expose the key anyway. In general, it is easier for an attacker to find and exploit client-side flaws (like XSS) than to hack into the server and extract the private key from there.

Improve this answer
2

You will have fallowing problem:

What if my original computer is dead and/or I want to use some other computer, where will I get public key? Nobody will be able to decrypt the data.

I would suggest you to do something like that:

  1. Each user has his own passphrase

  2. When user enter the data it gets encrypted with the symmetric key that build from some random key + passphrase

  3. random key get saved next to the data in the DB (but not the passphrase)

  4. When user wants to view the data he needs to provide the passphrase and then the data get decrypted

Improve this answer

You must log in to answer this question.