Make bcrypt work with &[u8]

[LukasKalbertodt]

Hi there!

I don't see a reason why bcrypt needs valid UTF-8 strings, so I guess it could be more general? Something like:

pub fn hash<P: AsRef<[u8]>>(pass: P) -> Result<String>

That way it works with all kinds of types, including &str and &[u8].

---

Maybe this applies to other hash functions, too. I only use bcrypt ^_^

[inejge]

It could accept [u8], I just never thought about extending the interface beyond the Unix-compatible version. Do you have a specific use case in mind for the more general hashing function?

[LukasKalbertodt]

What do you mean by "Unix-compatible" version? Is there an official bcrypt implementation that only works on UTF-8 strings?

Do you have a specific use case in mind for the more general hashing function?

Well, not really. While working on a project of mine, I wrote a trait Authenticator with a function auth(id: &str, secret: &[u8]) or something like that. I choose secret to be &[u8] to be able to use that trait with binary data (like keys), too. It was just by using that trait that I noticed that your crate only handles &str data...

Here it looks like you are working on the &[u8] slice internally anyway. So: why not expose that?

[inejge]

Is there an official bcrypt implementation that only works on UTF-8 strings?

There are two canonical implementations, OpenBSD and Openwall, both of which accept NUL-terminated C char strings, not arbitrary binary slices.

[...] it looks like you are working on the &[u8] slice internally anyway. So: why not expose that?

Nothing against the idea, I'd just prefer to bump the minor version of the library for that change, despite its backward compatibility. I wouldn't like to do that hastily, but I'm not sure I can devote much time to this crate presently. I asked about a specific use case because adding a bcrypt-specific hashing function which accepts &[u8] on input would be less disruptive, and could be done in a point release.