On 30 September 2026 16:47:30 BST, "Tim Düsterhus" <[email protected]> wrote: >I would. This is in fact almost exactly the behavior of the classic >`CRYPT_STD_DES` algorithm, except the limit is 8 bytes (with the high bit >ignored) with a 64 bit internal state: Even if the additional characters would >not be ignored, the 64 bit state means that there are equivalent inputs of 8 >bytes or fewer for inputs of 9 bytes or more.
Let's follow this example a bit: If a system used CRYPT_STD_DES, and limited user input to 8 bytes, you might have colliding hashes for "password" and "@7&jp9Q -". If the system did *not* limit user entry, it would have colliding hashes for "password1234" and "password !!! password". Note that both would pass a check for "include at least one digit or punctuation mark", but both would actually be breached by someone trying the input "password" which has neither. Now, truncating at 72 bytes is obviously very different from truncating at 8, but it's possible to imagine scenarios where it could lead to a meaningful loss of entropy. A quick search found this alphabet: <https://en.wikipedia.org/wiki/Osage_script> Stored high enough in Unicode that it requires 4 bytes of UTF-8 per character, *and* requires combining diacritics for some sounds. A diceware password of words in that script might truncate at 3 or 4 words. More likely, as already discussed, a developer misuses the API and prefixes a password, cutting the effective length limit. It seems to me that refusing those inputs and alerting the developer to the limitation leaves the *overall system* more secure. Hi Kamil, Tim, Replying to two messages in one here to cut down on traffic... On 30 September 2026 17:53:57 BST, Kamil Tekiela <[email protected]> wrote: >From a user's POV, it doesn't, and I agree with that. But that's not >very important for what we are discussing here. If it works as >designed, then it works correctly. I think this is the crux of our disagreement: I don't understand why the user's POV is "not very important". Rowan Tommins [IMSoP]
