Closed frank-dittrich closed 9 years ago
This is almost certainly something that SHOULD be hard coded. The format itself specifies 101 iterations. No where in searching, have I seen anything to show that iteration count can be set.
Note, there is not even a bbes10 'maker'. The hashes are not 100% the same. the $bbes10$ is fictional, and the separator char for the salt is a ':' which we change to a '$'. But the hashes I have seen are just the sha512 residue (in hex), and the salt
I am pretty sure this iteration part of the salt was some leftover from cut-paste from some other starting point format.
So we just remove the iterations from the salt, to avoid confusion? @kholia what do you think?
I'm moving this to J2 milestone but that does not mean we can't touch it earlier!
I vote for keeping the iterations
parameter. Having an extra field (or two) helps in the case of future expansion (e.g. handling more sub-types, algorithms, etc).
So we can close this, right?
The salt definition includes a component
iterations
which is never used. crypt_all seems to use a hard coded value of 99. Who knows whether this format should handle a varying iteration count? (If the number of iterations isn't a constant, it should be reported as a tunable cost.)