I need to get an int, derived by a given password, to feed it to a deterministic PRNG as a seed. The derived int should not give away any clues about the password.
How can I achieve this without getting too many collisions? (Because the integers are derived from a string that is much larger, I suspect that there will be many possible collisions, yet I want to minimize the chance of their occurrence.)
I have tried a few solutions and my current function strikes me as being too kludgy.
Here is the pseudocode of what I am doing right now:
password := getPasswordFromUser() salt_len := 16 salt := getRandomBytes(salt_len) // the password and salt is then put through a Key Derivation // function. The key will be used for encryption. // Here comes the part I have trouble with; to "randomize" the // order in which the data will be stored, I am using a deterministic // PRNG, which is seeded as follows: // Create a long string that contains the password: orderPasswd := password + "abcdefghijklmnopqrstuvwxyz" + "1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ.,;:#+!§$%&/()=?" // Create a sha256 sum of this string, feed it to the // deterministic PRNG as seed and shuffle the string: orderPwHash := sha256sum(orderPasswd) // derive an int from the hash by converting it orderPwSeed := int64(binary.BigEndian.Uint64(orderPwHash)) // shuffle orderPasswd using the Fisher-Yates shuffle algorithm orderPasswd = shuffle(orderPasswd, orderPwSeed) // Put orderPasswd through the KDF, hash the key and shuffle // the order with an integer derived from the hash: orderKey := getKey(string(orderPasswd[salt_len:]), orderPasswd[:salt_len]) orderKeyHash := sha256sum(orderKey) // convert that hash to an integer to finally get the seed // that will be used to determine the order orderSeed := int64(binary.BigEndian.Uint64(orderKeyHash)) // seed the PRNG with orderSeed... shuffle the order...
I have accepted Ilmari Karonen's answer, because he put a lot of effort into it and it contains vital information for anyone trying to implement cryptography.
I have dismissed the idea of shuffling the message, as it would unnecessarily complicate my code and increase the likeliness of mistakes without adding to the security, which is especially bad in this context.
Because the message, once encrypted with AES256 and a key derived with scrypt set with N=65536 and p=2, will look like random noise, this ought to be sufficient.