0

what I Know: Password based key derivation functions generate a key suitable for ciphers from a given password. It relies only on the original password being kept secret.

The purpose of the salt is simply to prevent the use of rainbow tables. A rainbow table would have to be made for each salt, and if (as is common practise), each user has their own salt, a rainbow table would have to be constructed for that particular user. In general it is not assumed to be secret.

Salts are used in conjunction with a higher number of iterations inside the PBKDF function to hinder any attempt to create a rainbow table.

The key derived from the PBKDF2 can used as AES key to encypt data.

My problem: Lets say in some limited world, I only can use user's Email as an input for Key derivation functions like Scrypt, The salt is also used to the reasons mentioned above.

Since email can be guesses easily, so the scrypt keys but not the salt. Isnt it a better approach to hide the salt, so that the attacked couldnt bruteforce the scrypt keys? If the attacker wants to guess the salt, it will be difficult for him as it will be of 16 bytes.

Note: The scrypt keys are used to encrypt some data, which will then be distributed to various other parties. The salt will be stored in the database. Theoretically, decryption of this data by a single party is impossible, since no one has complete information. DB only has salt, other parties only have shares of the file data not the complete data.

||improve this question
  • There is ID based Cryptography that you might interest. – kelalaka Dec 25 '18 at 19:55
  • The whole point is to store the data decentrally, Using a central party who must be trusted would kill the whole purpose, Please help me here. – saurav verma Dec 25 '18 at 19:59
  • The whole point of a KDF is to use some secret only known to the user and derive a key from it. You instead want to have as input a value known to the attacker (the email) and a value which you need to store somewhere to recreate the key (the salt). This simply makes no sense: to derive some secret for the user you need to have something as input which is only known to the user. – Steffen Ullrich Dec 25 '18 at 21:42
  • I am using user's email which is known to the user obviously, but lets say an attacker knows this user, then guessing his email is pretty easy. – saurav verma Dec 25 '18 at 22:19
1

What you are doing is a building a key derivation function and you seem to understand the basics. However with any KDF there's some "secret". Salts are as what you mentioned, used to prevent rainbow table attacks, they are not considered "secret".

Rather than making it so difficult for yourself, you should look into multi-party or group encryption. Group encryption algorithms strive to achieve the following: a given message is encrypted, and may be decrypted only if sufficiently many group members collaborate.

Have a look at this post on crypto stackexchange as well

||improve this answer
  • The secret after encryption with scrypt key will split using Shania secret and then distributed among other parties. I just want that if the parties collude, they shouldn't be able to decrypt it. – saurav verma Dec 26 '18 at 8:04
  • Salts don't prevent brute force. They force password crackers to use brute force. – Future Security Dec 27 '18 at 18:37
  • @FutureSecurity ha, updated youre right – Lucas Kauffman Dec 28 '18 at 1:02
  • I already have implemented group Encyption, the point is if they collude, i want to make it difficult for them to recover the original secret, – saurav verma Jan 2 '19 at 0:00
  • @sauravverma require more group members... – Lucas Kauffman Jan 2 '19 at 0:01
0

Key derivation functions such as PBKDF2 are meant for transforming a bad password into a strong key by needing a lot of work for the derivation. You just want a multi-party encryption. You can probably skip all of that and just create random keys for each person.

But this is probably best asked on https://crypto.stackexchange.com as mentioned in the other answer.

||improve this answer
  • Every user who will have their share of the password, will have their own asymmetric keys. – saurav verma Dec 27 '18 at 15:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.