On Sun, Nov 23, 2014 at 01:42, Jonas 'Sortie' Termansen wrote: > > This can be easily solved if crypt_checkpass checks the hash doesn't start > with > '$' and then calls the utility crypt_hashpass directly (will need to be > visible > from outside its current translation unit), and storing the temporary hash > in a > little stack buffer (21 bytes is sufficient). The DES tables must also be > safely > initialized with a once lock, or precomputed at compile time. Alternatively, > support for checking older hashes could be dropped altogether.
Cleaing up the DES crypt code was on my list for a while, but I got kind of sidetracked. Fixing the code now competes with deleting the code for priority, but since we probably can't do without it entirely, I'll have to fix it eventually. The lack of thread safety should be considered a bug in the implementation. > > Third, the purpose of the hashlen parameter to bcrypt_newhash(3) and > crypt_newhash(3) is undocumented, but judging from its name and uses > across the > tree, it obviously looks like the size of the hash buffer for bounds-checking > purposes. bcrypt_hashpass(3) never uses the size of the buffer, despite > printing > and base64 encoding into it! Yup. As you noticed, the existing code still has more than a few remnants of origins.
