Ask HN: Is it enough to use XOR encryption for my journal app?
I don't want my employees or myself to see the user's data in the backend. Considering it's just a journal app, is it enough to use XOR encryption in the client, or do I need to use something else?
7 comments
What are your users journaling about? Do you think it’s possible they could be journaling about things that, in their region, could lead to prosecution? Ostracization? Take your user’s security seriously. You don’t know what they are putting in “just a journal app”
Is asking the user to set and remember an encryption string the correct way? The only downside I can think of is that he may forget it, which is irrecoverable.
At least double XOR it, then it's fairly safe and while not quantum safe, it'll keep them wondering.
XOR alone isn't encryption. Just use AES and other conventional encryption algorithms.
This. I'm not sure why this is even a question.
Just because I'm in a pedantic mood, you can technically have very strong encryption using XOR, but it's not at all practical because you need to XOR your data with a truly random series of values that is as long as the data itself. If that series isn't actually and truly random, then the scheme becomes breakable. That random series of values is both the encryption and decryption key. It's equivalent to using a one-time pad, with all the advantages and disadvantages that brings.
It's not usually practical because you have to store or transmit that key in some way, and if that way isn't itself totally secure then your scheme is not secure. If you can store or transmit that key securely, then you can also (in the vast majority of cases) store or transmit the data you want to encrypt securely, so you haven't gained anything.
This is a real case of "just use a crypto library and be done with it."
Just because I'm in a pedantic mood, you can technically have very strong encryption using XOR, but it's not at all practical because you need to XOR your data with a truly random series of values that is as long as the data itself. If that series isn't actually and truly random, then the scheme becomes breakable. That random series of values is both the encryption and decryption key. It's equivalent to using a one-time pad, with all the advantages and disadvantages that brings.
It's not usually practical because you have to store or transmit that key in some way, and if that way isn't itself totally secure then your scheme is not secure. If you can store or transmit that key securely, then you can also (in the vast majority of cases) store or transmit the data you want to encrypt securely, so you haven't gained anything.
This is a real case of "just use a crypto library and be done with it."
Thank you. Is asking the user to set and remember an encryption string the correct way? The only downside I can think of is that he may forget it, which is irrecoverable.
If your goal is just to do a quick obfuscation, then it would be OK (and better than nothing) just as long as you never claim to users that you're storing the data in an encrypted or secure form. Saying that would lead to a security expectation that you aren't meeting.
> Is asking the user to set and remember an encryption string the correct way?
That wouldn't be remotely sufficient for two reasons:
1) The user-supplied string will not to be random.
2) You need a constant series of random values that is as long as the data you're wanting to encrypt. If the user is securing a 2k long ASCII text, then you need 2k new random numbers for it.
> Is asking the user to set and remember an encryption string the correct way?
That wouldn't be remotely sufficient for two reasons:
1) The user-supplied string will not to be random.
2) You need a constant series of random values that is as long as the data you're wanting to encrypt. If the user is securing a 2k long ASCII text, then you need 2k new random numbers for it.