Being not a cryptography expert, I am having some basic questions on how to manage keys wrt. sodium-plus. Let me briefly explain the context: the use case involves sending data from a web frontend to a backend, but the backend should not be able to read it (deliberate design choice due to privacy concerns). The data in question needs to be usable from different client machines (the same frontend used at different times on differnet machines). It should be en- and decrypted using a secret that is under the control of the user and not stored by the application. There is no second user involved that should be able to decrypt the data, so I see this as a scenario for using a shared-key encyption approach.
I am looking into using sodium-plus.js for this and in particular to use
crypto_secretbox, but am actually not clear on how to manage the key part in the scenario — ultimately, the user needs to have a way to access the same data on a different machine. Looking through the API documentation, I see two options:
- Generate a random key, convert it to a hex string, present the hex presentation to the user and leave it up to the user how she stores it. Then the user could use this hex presentation on the next client machine to decrypt her data.
Unfortunately, I seem to be unable to re-create a cryptographic key from the hex presentation (
hex2binreturns a (Promise for a) string). Is this even feasible? Also, I’m not at all convinced that this approach is not entirely defeating the idea of generating a random key in the first place?
- Derive a key from a password via
crypto_pwhashthat the user has to specify. However, this requires also a salt, so I’m back in a similar unclear situation on how to handle it: if the user would give the same password on a different machine (on which to decrypt the data) I also have to use the same salt to generate the same cryptographic key. How do people handle this?
If I could easily have read up on all of this, I would appreciate pointers, as my search-fu seems to fail me.
Go to Source