Function to derive an integer from a given password 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.,;:#+!§$%&amp;/()=?"
// 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...


Edit:

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.
If you have access to a PBKDF2 implementation, I'd just take a 8 byte output of PBKDF2. Whether that's a Little Endian or Big Endian value doesn't matter so long as you're consistent.

Since PBKDF2 has good spread, a 64-bit capture from it gets a 50% chance of collision around the 5.1 billionth different input, still down at 1% around 600 million.  (See the table on Birthday Attack.)