Contents

Talk:Bcrypt

This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computing: Software / Free and open-source software Mid‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles Mid This article has been rated as Mid-importance on the project's importance scale. This article is supported by WikiProject Software (assessed as Mid-importance). This article is supported by Free and open-source software (assessed as Mid-importance). Cryptography: Computer science Mid‑importance This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography articles Mid This article has been rated as Mid-importance on the importance scale. This article is supported by WikiProject Computer science (assessed as Mid-importance).

bcrypt is not a key derivation function[edit]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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. ^[1] 2605:E000:1524:C004:A85D:D4F0:81F8:F488 (talk) 11:41, 18 September 2014 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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.htmltohttps://www.suse.com/support/security/advisories/2011_35_blowfish.html

When you have finished reviewing my changes, please set the checked parameter below to trueorfailed 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]