Talk:Bcrypt

bcrypt is not a key derivation function

The lead of this article describes bcrypt as a KDF. This is wrong:

• Nowhere in the original paper is bcrypt referred to as a KDF. It's specifically called a "hash function" or "password hashing function" in the paper: https://www.usenix.org/legacy/event/usenix99/full_papers/provos/provos.pdf
• bcrypt does not meet the criteria on a KDF as described in the Wikipedia key derivation function page. These properties include: deriving one _or more_ secret keys from a master secret and stretching key into longer keys. Where typical KDFs produce variable length outputs, the bcrypt paper describes a function that only produces a 192-bit output, and in practice bcrypt produces 184-bits. This can't even be used to derive e.g. a 256-bit encryption key (or multiple 128-bit keys from a single input).
• Where PBKDF2 and scrypt are commonly used to derive keys, bcrypt is not: it is used nearly exclusively for password storage. The Wikipedia key derivation function page notes that "KDFs happen to have the characteristics desired for a 'password hash function', even though they were not originally designed for this purpose" however the reverse is not necessarily true. Where password hashing functions like PBKDF2, scrypt, and Argon2 are KDFs, bcrypt does not provide the basic features of a KDF.

There is a KDF based on bcrypt used by e.g. OpenSSH, namely a variant of PBKDF2 which uses bcrypt as its PRF, but in this case the real KDF is PBKDF2, not bcrypt: bcrypt is simply acting as a PRF.

I challenge anyone claiming bcrypt itself is a KDF to find any reputable source saying so. That said I'm going to change it to "password hashing function" to match what's in the paper. Tarcieri (talk) 21:21, 8 May 2016 (UTC)

I'm 5 years late, but I agree that this is not a KDF and the article should not call it one. BernardoSulzbach (talk) 15:27, 4 July 2021 (UTC)

Seriously misleading description, now fixed

This fragment "(.. bcrypt computes..) a hash from a given input as follows: bcrypt(cost, salt, key, input)" suggested that the password is fed in input. But the intend in the original definition, and many implementations, is feeding password in key, with input a constant derived from "OrpheanBeholderScryDoubt" broken as three 64-bit blocks. Now fixed. Fgrieu (talk) 20:27, 26 June 2012 (UTC)

Popular password hashing bcrypt vs later obscure file encryption bcrypt

I bet 99% of people looking for bcrypt think of the password derivation function, not a pretty obscure program using an outdated cipher... JidGom (talk) (2011-03-30T04:58:28)

We had the same thought on the same day. Right - all the links to bcrypt on wikipedia were about the hash. And the hash is about more than the "crypt (Unix)" program. So I fixed it. ★NealMcB★ (talk) 15:35, 30 March 2011 (UTC)

I came here today looking for information on the unix command, since I downloaded it and it does NOT seem to implement a hash function. I would have liked to have found that information here. DouglasHeld (talk) 15:51, 11 January 2018 (UTC)

Cryptographic hash function page

Why isn't this page listed in the Cryptographic hash function page and corresponding template? Dserodio (talk) 20:32, 20 August 2012 (UTC)

Technically it's not a hash, it's a Key derivation function.

At least some Wikipedia user claims this is not the case and that there are no references found stating that bcrypt is a key derivation function (KDF). Now how would be an authoritative source to clear this once and for all? Or is there consent now that bcrypt is no KDF? --79.212.58.2 (talk) 14:47, 7 June 2020 (UTC)

Explain What Bcrypt Does, Not How It Is Implemented

The article lacks a clear statement about how Bcrypt is different from other hashing functions. What parts are essential to its functioning and how it may be used. I.e. something that would speak to the broader audience of people not versed in cryptography, users of cryptography, not cryptographers themselves. An explanation would be especially beneficial because most times I've seen it being used, it was used wrongly. The fact that it uses the hash, previously generated from input to produce the salt when verifying that the hash generated from another input matches the hash generated from the previous input - is very counter-intuitive and deserves special attention IMO. 79.176.130.107 (talk) 14:02, 9 October 2013 (UTC)

ExpandKey function code looks wrong

what I can see: it takes an input, does lots of stuff, discards it and returns the input state. — Preceding unsigned comment added by 84.146.72.200 (talk) 19:20, 21 January 2014 (UTC)

I second that. It looks like a no-op, returning the same `state` that was passed as a parameter. This makes no sense. Tempel (talk) 07:38, 30 August 2016 (UTC)

Bcrypt does not return a 192 bit hash

It was *meant* to, but the original implementation differed from the paper. There's a bug leading to the last byte of the output not being returned, which gives a total hash size of 184 bits. This mistake has basically become canonical (at least in the 2a implementation) and is mirrored in all other implementations of the algorithm that I've come across. 2605:E000:1524:C004:A85D:D4F0:81F8:F488 (talk) 11:41, 18 September 2014 (UTC)

References

Bcrypt hash prefixes

The crypt_blowfish-1.3 package includes the following note: OpenBSD 5.5 introduced the "$2b$" prefix for behavior that exactly matches crypt_blowfish's "$2y$", and current crypt_blowfish supports it as well. There are now four possible labels: "$2a$", "$2x$", "$2y$", "$2b$". The first is riddled with uncertainties, the second is (intentionally) buggy, the third redundant (equivalent to the fourth). As such, the first three might all be considered deprecated, though someone with insight ought to weigh in on this matter. Actually, there's also the fifth, "$2$" label, but this variant hasn't seen any use, I presume. See also Crypt_(C)#Blowfish-based_scheme. Meanwhile, the detail that only 23 bytes of hash value are encoded in the result (as noted above), has not changed. — Preceding unsigned comment added by 217.71.44.75 (talk) 03:48, 20 May 2015 (UTC)

Looks like the "$2x$", "$2y$" variants are only used by some php implementation which had some bug on its own and thus they're mostly superflous.--2A02:8070:6394:7A00:A4EF:3107:3608:F7A8 (talk) 19:06, 30 December 2021 (UTC)

This is an incorrect summation. The implementation PHP uses is the same one everyone else uses, the bug was in ALL versions of crypt_blowfish and fixed upstream by Solar Designer. The only involvement PHP had in the process is that I was writing a test suite for various crypt algorithms to be used in validation when PHP is being built from source on various platforms.

(Source: I am the person who found and identified the bug and reported it upstream.) 209.35.184.219 (talk) 01:00, 16 November 2024 (UTC)

The Example: Placement and Completeness

The example is very useful, but is lacking what the actual input password was, and probably should be in it's own section. --Osndok (talk) 00:53, 19 July 2015 (UTC)

ashley madison?

how about someone add something about how Ashley Madison was using this supposedly awesome (according to this wiki) encryption method, and yet it clearly didn't work out so well for them? .... — Preceding unsigned comment added by 24.246.14.180 (talk) 03:56, 25 August 2015 (UTC)

Doesn't belong here. bcrypt is just a means of protecting passwords in a service's database and it did its job [1]. bcrypt cannot protect anything else from leaks, hacking or social engineering. -- intgr [talk] 08:21, 25 August 2015 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Bcrypt. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20160304094921/https://www.suse.com/support/security/advisories/2011_35_blowfish.html to https://www.suse.com/support/security/advisories/2011_35_blowfish.html

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 06:18, 29 October 2016 (UTC)

Why listing so many programming languages in the introduction?

Seems like I should add my favorite programming language there as well. Yes, implementations exist for all these but why list those and not more? Or better do it differently: "Implementations exist for most popular programming languages." There is no need to list the languages, unless one list specific implementations and then only such should be listed which have something special.--2A02:8070:6394:7A00:8910:5CC1:B853:F69D (talk) 10:53, 5 January 2022 (UTC)

Discrepancy in maximum password length

The English article states a maximum password length of 72 byte while the German article claims the maximum would be 56 byte. Now who's right?--2A02:8070:6394:7A00:7D29:E559:AC6:C44B (talk) 15:48, 12 February 2022 (UTC)

Next password length discrepancy

The article contains these two citations, but it's not clear to me whether the 72 byte limit has been relaxed nowadays or where otherwise the 255 comes from:

"bcrypt has a maximum password length of 72 bytes" vs. "If a password was longer than 255 characters, it would overflow and wrap at 255"

Can somebody explain this please?--2A02:8070:6394:7A00:8964:C260:9A4E:B279 (talk) 17:53, 17 February 2022 (UTC)

See edits that I just made at the end of the "Version History" section about the $2b$ version. netjeff (talk) 06:38, 18 February 2022 (UTC)