How does one-way encryption work?

I don't understand how it's possible for one-way encryption to be a thing. If a function isn't injective then different passwords would be hashed to the same string, making it insecure. If it is injective then it can be turned into a bijective function by restricting its codomain to its image and all bijective functions are invertible. How does something like sha256 work? Am I missing something really obvious?

Pretty much all cryptography relies on things being computationally infeasible, not provably impossible. If two passwords will hash to the same value, but it will take thousands of years to compute a collision according to our projected technological improvements, it is good enough. This is why people get in a panic about quantum computers etc

>>28290 Something something symmetric keys. Basically, you can't reverse every procedure without losing data, for example it is easy to see that 123488128348 * 8854300091251235235 = 1093400946100140648613219941780 But if you're only given the number 1093400946100140648613219941780 and know that numbers a * b created it, it is not easy to guess what is a and what is b. On the other hand, if you have a = 123488128348 (key) and 1093400946100140648613219941780 (encrypted message), you can easily tell what is b (message). Encryption works like this but the mathematical framework behind it is more complicated.

Also, just because a function is invertible doesn't mean we know/can easily compute the inverse.

sha256 is not injective. It can't be - it outputs a fixed-size hash value for any size input. Basic pigeonhole principle tells us it must not be injective.

>If a function isn't injective then different passwords would be hashed to the same string, making it insecure. there's nothing insecure about that if the chances of a collision are astronomically low (typically 1 in 2^128 or 1 in 100000000000000000000000000000000000000 is considered 'good enough'). It's more likely that two people pick the same password than that you get a collision. >all bijective functions are invertible this is true but that doesn't mean it is easy to find the inverse. Typically, if a hash function is bijective on some inputs, then it would be considered "good enough" only if there is no known way to invert the function besides making a list of all inputs and outputs.

Look at the numbers >>28412 gives. Modern hash algorithms technically have collisions but finding one is not going to happen and if you did one or both of the inputs would probably have a cosmic filesize too.

>>28291 >go through all the trouble to bcrypt passwords >uses lots of rounds making hashs take 10s of milliseconds >wrap yourself in a warm security blanket >deploy to production >site instant cracked because bcyrpt isn't collision resistant Present Day, Present Time! AHAHAHAHAHA!

>>28290 This thread belongs on /sec/ Lots of great answers already though, the fuarrrk is bijective?!??

>>28437 Injective, Surjective and Bijective describe relationships between a function's input and output. In a bijective function each input maps to only one unique output and the set of possible inputs and outputs are of equal size.

>>28437 a "function" is a way to associate to each object in A to exactly one object in B. this function is injective if no two objects in A are associated to the same object in B it is surjective if every object in A is associated to an object in B it is bijective if it is both injective and surjective. This is equivalent to having an "inverse function", meaning, a function g such that f(g(x)) = x and g(f(y)) = y for any x in B and y in A. https://en.wikipedia.org/wiki/Bijection >>28424 bcrypt isn't collision resistant? Do you have some data on that? I've never heard of weaknesses in the blowfish cipher. In any case, you shouldn't be leaking your database that easily anyway.

>>28441 >you shouldn't be leaking your database that easily anyway. That's not the issue. If every password collides, then every login works, regardless if the password is correct. That's worst case. If a hash function isn't collision resistant, then many passwords can work to log into an account. With collision resistance, only the correct password can be used to log in.

>>28497 >If every password collides, then every login works, regardless if the password is correct. Okay, have you actually demonstrated that collisions are frequent enough that this is a problem? Collision resistance isn't even generally considered a cryptographic property.