>you can make a hash out of a file >changing one single

you might as well randomly generate a binary string and hope it turns out to be photoshop and not cheese pizza

That's not how computers work son. Get back to flippin' burgers

a hash doesn't correspond to a unique file

Are you literally retarded or just a fucking idiot?

>>59621253
Because its only an identifer, not the actual data

Kill yourself, you fucking mong.

>>59621253
avg /g/ poster

>>59621253
This is actually decent bait.

It sounds like a genuine misunderstanding that a computer illiterate could make.

>>59621299
>>59621328
>>59621340
>>59621351
Funny how you faggots mock but you do nothing to elaborate on your post, other than trying to be funny and hardcore.

Jokes on you though. I can store all data using pi. https://github.com/philipl/pifs

What are you going to do now, faggots? Kill yourselves.

>>59621308
So we could save a hash and, like, the first x bytes so you know when you found the file in question.

>>59621253
You're actually right but the problem is that all hashes have collisions. This is normally not a problem since the chance of a collision is small but when you're doing the process in reverse there's an infinite number of files that could be created from your hash.

>>59621408
Shit anon finally a use for my raspberry pi. Thanks!

@59621408

*yawn*

>>59621253
>Not knowing what one-way-functions are
>Being a math pleb

>>59621496
What if you had like multiple hashes? To ensure you have bruteforced the correct file? By the way does this means having multiple hashes is less safe? (Which isn't the point in this case, of course.)

>>59621408
>(You)

>>59621526
I'm a ̶p̶a̶r̶a̶s̶i̶t̶e̶ lawyer.

>>59621526
>one-way-functions
>"it can be done but i have mathematical proof that it's too hard"
WELL TRY HARDER

>>59621563
What is encryption? What is RSA? What are prime numbers? How do you define hard"? What is maths?

>>59621253
Lets see an example. Consider,

>2+2=4
>3+1=4
>5-1=4

Here, 4 is the hash but you have no way of know which combination of operations produced this hash since many combinations can do this. This is the basic problem.

>>59621253
>hash is just signature to verify data integrity

It's a common beginner mistake to assume a hash is the same as encryption.

:^D

>>59621619
Hashing is different because it's one to one

>>59621724
No it isn't. It could only be 1:1 if the hash was as long as the longest file you wanted to put into your hashing scheme. How could all the possible 1KiB files map onto one 20 byte hash (as in SHA-1)? In this scenario there's 2^160 possible hashes and 2^8192 possible files. It's just not possible.

>>59621723
You can encrypt using hashes like MD5, very common with passwords to hash and salt it.

File: Self MD5.gif (84KB, 855x203px) Image search: [Google]

84KB, 855x203px

>>59621253
>Why can't we make files out of hashes
Check my hash.

>>59621442
And the lenght. There's an infinite amount of numbers beginning with same symbols and producing same hash.

>>59621253
fucking hash collisions, man

File: Sketch (10).png (447KB, 802x451px) Image search: [Google]

447KB, 802x451px

damn google you failed me today

>>59621253
That's nothing. Look up PiFS. You already have every file that will ever be created, you just have to generate the metadata for it.

>>59621556
It shows

File: bf2.jpg (172KB, 600x407px) Image search: [Google]

172KB, 600x407px

>>59621914
Damnit, now I want hash browns. Thank god Mcdonald's has all-day breakfast now, the ones at Tim Hortons/A&W simply aren't as good as these greasy, artery-clogging beauties.

File: 1489880992672.jpg (60KB, 953x1280px) Image search: [Google]

60KB, 953x1280px

>>59621291

To elaborate on what people are saying: not only do you have collisions, but the problem is that with one-way functions it can take on the order of trillions of years, utilising the entire theoretical computing power of the universe (i.e. turn every single atom in the universe into part of a giant computing unit), to reverse the function.

That's why, for instance, even an encrypted file, where encryption IS one-to-one, cannot be used to recover the original.

>>59621992
>From here, it is a small leap to see that if π contains all possible files, why are we wasting exabytes of space storing those files, when we could just look them up in π!

why not just mount /dev/random or /dev/urandom instead?

>>59621827
then you could just save the whole file and add the hash to the end

>>59621992
>Why is this thing so slow? It took me five minutes to store a 400 line text file!
KEK
Yeah, you "just" have to generate the metadata for it.

It's a neat idea, but the fact that your data will """"""""""""""""""""""""""""""""""""""""eventually"""""""""""""""""""""""""""""""""""""""" occur in pi's digit sequence just means it's a way of storing your files. It doesn't mean it's a PRACTICAL way of storing your files -- and it never will be, because its capacity for unprecedented impracticality is literally infinite.

>>59621291
I think you got that backwards

>>59621596
He's right, hash functions are not one way (also, hash functions like the SHA2 family are NOT cryptographic functions necessarily, those would be cryptographic hash functions such as bcrypt), just proven to be difficult to result in collisions, which are still very possible. Tard, don't act so high and might when you don't know what you're talking about.

>>59622089
Because:

a) It's not guaranteed that every possible combination will come up. Yes, the probability will tend to one, but you would need to search for an infinite amount of time to get probability of finding your file as exactly 1.

b) There's no easy way to re-generate the same sequence. With π, you literally just look up the sequence at the predefined location. With /dev/random, what will you store and how will you recall the file?

You could, however, use a deterministic pseudorandom number generator and store the seed for it to re-generate your file, but that boils down almost to the same thing as using π, except with problem a) still present.

>>59621799
>hashing with md5
we weas romanz and shee

>>59622165
There's nothing cryptographically wrong with hashing passwords with MD5 IIRC, it's just that it's so fast that you have to take absurd measures to prevent any basement hacker from trying out trillions of hashes per second or something like that.

>>59622192
>hitler did nothing wrong
that's how you sound

>>59622207
He does sound correct.

>>59622074
>mc griddle and sausage
>orange juice/ mccoffee
>hashbrown

ahh the nostalga of working minimum wage and waking up late

>>59622160
a) Not guaranteed for pi either, still hasn't been proven normal.

>>59621408
you cant go from a hash to a file you retard.

>>59622192
>There's nothing cryptographically wrong with hashing passwords with MD5 IIRC,
Yes there is.
>it's just that it's so fast that you have to take absurd measures to prevent any basement hacker from trying out trillions of hashes per second or something like that.
And that's it.

>>59622223
True, but that software is operating under the assumption that it is normal.

If it's not then, well, woopsies.

>>59622192
md5 is insecure, has been for years

>>59621253
What you are talking about is the same as a youtube url https://www.youtube.com/watch?v=dQw4w9WgXcQ

dQw4w9WgXcQ is counting using 0-9 a-z A-Z _ and - It's only an index and a source of the real content still has to exist.

If you have internet speed that is negligible to on site hardware, and an indexing system like this, then it would work.

>>59621724
Take a course on elementary set theory, anon. There can't be a bijective function between two sets of different cardinality, that's kinda the whole point of it.

>>59622229
Sure you can. Multiple times, in fact. The problem is:
1) most of the files will be meaningless non-executable binaries
2) there will be infinitely many to check, or at least absurdly many

>>59622255
But they aren't of different cardinality. There are just as many valid files as possible hashes, the difference in length is irrelevant

>>59622268
you are an idiot

>>59622246
>Not using salt

>>59622246
To collision attacks, not pre-image attacks, meaning that there's no attack or vulnerability that makes it unsuitable for hashing passwords.

Although as >>59622235 pointed out, you should still use other things because it's intrinsically bad, but that's just due to the hashing function's properties, not due to any attack.

>>59622306
>not using an actual good, crytographic hash algorithm like bcrypt

>>59622297
Okay look just because there are only n varying parts to X and m varying parts to Y, where m > n and all such parts have p possible variations each, DOESN'T FUCKING MEAN there are more possible Y than possible X!!!

i mean it's not like the number of possible X is n^p and the number of possible Y is m^p, and because m > n and p is semantically mandated to be a positive integer, m^p is greater than n^p. Anyone who would say THAT is the REAL idiot here.

>>59622313
>To collision attacks
which is a really big deal

>>59622341
thanks for confirming once again

>>59622306
>not using pepper

>>59622268
Take a 256-bit hash digest. There are exactly 2^256 different possible hashes, not more.

Now take a 1KiB file. It is still a valid file even if it consists entirely of random data - in fact, if you take a meaningful file, and encrypt it with an OTP, the result will be indistinguishable from random data, and by varying the pad you can arrive at any possible end combination of data, so it's actually practically possible to have any combination of those 1024 bits be a real-life file.

So, you have 2^1024 possible files.

Now please explain how the length does not matter, or how 2^256 = 2^1024?

I store all my meme files as a string description of the file and the sha256 of the file. Then my custom filesystem queries Google for the description and returns the first result matching the sha1. Gets like a 0.1% compression ratio. Fault tolerance is achieved by failing over to Yandex and Bing. Data is automatically redundantly stored based on social importance via cross site posting and reposts.

>>59622347
But completely irrelevant to password hashing.

>>59622370
Meant sha256 in the second part there. I recently switched since sha1 is so broken.

File: 1489259724645.jpg (38KB, 500x667px) Image search: [Google]

38KB, 500x667px

>>59622341
Woops I just got baited >>59622367

>>59621253
I have a 1GB file at the resource, http://mofowebsite6-a-z2.com/resource?in=a
a 2GB at
http://mofowebsite6-a-z2.com/resource?in=b
a 2TB at
http://mofowebsite6-a-z2.com/resource?in=c
All I had to remember was one character of information for 2TB! 99.999999999% compression!

>>59622367
>Take a 256-bit hash digest. There are exactly 2^256 different possible hashes, not more.
I reject this premise. You can't just calculate the number of possibilities as the number of possible variations of each part to the power of the number of parts. That's a stupid meme.

>>59622261
>Sure you can
>but it's going to be all fucked up
Really?

>>59622379
Except it means you don't need to know someone's password to get into their account, just something that collides to the same hash, thus making it less secure, even for password hashing.

>>59622261
>Sure you can. Multiple times,
nope, good try retard.

>>59622408
And why is that?

>>59622507
That's a pre-image attack, which I specifically said MD5 is NOT particularly vulnerable to.

Pigeonhole principle.

/thread

>>59621253
Shitposting at its finest

>>59622577
Except it's more vulnerable than good algorithms by the very nature of its hash collision inefficiencies. Am I wrong?

>>59622679
Not particularly. According to wikipedia the best preimage attack on MD5 is a theoretical attack with complexity 2^123.4.

You could argue that it's less secure than the best hash functions, such as SHA-256, and I would agree, but that doesn't mean that it's broken by any means

(It does, however, mean that there's no reason to use it if a provably more secure alternative exists, which does. I'm just trying to point out that screaming "REEEE INSECURE" is not technically correct. If, however, some arbitrary restriction forced you to implement a secure password storage scheme using only MD5, it would be perfectly feasible.)

>>59621799
>Hey this hash is unintentionally broken and can be reversed

/g/ is fucking silly

1) Store the hash of a file and the size (N) of it
2) Try every combination

Good luck, there will be 256^N combinations

>>59622833
>You could argue that it's less secure than the best hash functions
Which is exactly what I said. You're agreeing with me, my dude.

>>59626030
Pretty sure you said it was broken/insecure (which it is not).

If all you were saying is that it's less secure, then in that case, yes, that was a misunderstanding, and I do agree with you.

>>59626171
Yes, I was saying it's less secure than other hashing algorithms. Also, security is relative, if md5 is the least secure hsahing algorithm among the ones in use today, then relatively, it is insecure. So while i wasn't saying that, now I am.

>>59621253
>doesn't understanding that hashing is one way

>>59621496
No he's not right. Collisions are the smallest issues with OP's idea

>>59621529
See above response. The guy you replied to is retarded. For your last question, the more hashes you have the better. It's much harder to have the same collision in five different algorithms than a collision with a single algorithm

>>59626193
>relatively, it is insecure
But non-relatively, if your passwords can withstand an attacker with a large dedicated hashing rig and stuff for 1,000,000 years, I wouldn't call it insecure. Even if all other algorithms may withstand 1,000,000,000 years instead, right now it's not relevant (and since Moore's law is failing, is unlikely to become relevant until quantum computing or something similar results in a revolution in computing).

>>59626349
It could still be called insecure if the requirement for "security" would be that it needed to withstand 5,000,000 years or something. The point is, there is no defined requirement, so only relative comparissons matter, therefore md5 is an insecure hash algorithm.

>>59626451
Yeah there is a defined requirement, it's that a hacked shouldn't be able to get the data.

No hacker will be alive for 1,000,000 years, so they won't be able to get the data.

>>59626574
>it's that a hacked shouldn't be able to get the data
If that's the case, then no hashing algorithm is secure, because theoretically, they can all be broken by hackers (a method just hasn't been found). But based on the information we have so far and the fact that only relative security matters, md5 is insecure.

Fucking shit guys it's not like SHA-256 has a licensing fee. The only reason not to use it is developer laziness, pure and simple.

>>59621914
I searched "maki face" earlier. You're not going to see an anime character.

We could try.

Save a unique hash and then randomize bits until the hash fits.

Should only take gazillions of years of computing power

>>59622207
Why do you think Hitler was successful? By doing everything the wrong way?

File: fig7.png (16KB, 384x348px) Image search: [Google]

16KB, 384x348px

Hashes are not unique. hash collisions occur, and is a real problem when managing big data.

All hashes generated by a hashing function will be the same length, no matter how long or short the input. Think about how that is possible!

As a bottom line, most hashing methods will generate the same hash, when a generated hash is again passed to the same hashing function. This is the point of hashing functions, not a bug, a feature!

File: Screen_Shot_2014-06-02_at_10.22.12_AM.png (1MB, 1423x782px) Image search: [Google]

1MB, 1423x782px

I just had a revelation thanks to your stupid thread.

A hash based compression algorithm:

[1] Take the original file and 'hash' it.
[2] Take a small portion of the original file, 100KB would do.
[3] Create a file including [1] and [2], indicating what part is the hash and what is the portion of the original file
[4] Distribute the file from [3]

User receives the file and executes the decompressor, which does the following:

[5] create a list of al the possible original files that could have generated that hash
[6] selects the one that with the small portion of the original file in it and generates it.
[7] ???
[8] profit

>>59621253
Because its not a true 1 to 1 mapping. There are always going to be collisions.

>>59630024
It won't work since it still has potential for collisions. . If your hash is 256 bits then all any 256 bit or larger sequence will have the potential to collide.

For example if you have 100KB of data that you hash and then brute force concatenate data to the end of it, then it will find a collision while trying the next 32 bytes.

>>59627010
rough anon.... reminds me when i was just a lad and a google image search of 12 gauge (i was like 10 and thought counterstrike spas 12 was cool) brought up some fool who offed himself with a 12 gauge. ill never forget it, looked like his face was deflated.
that shit scarred me

>>59622397
Elaborate.

>>59621408
>Jokes on you though. I can store all data using pi. https://github.com/philipl/pifs
Here's a funny thing, the offsets required to store your files will on average be just as big as your files.

The author knows that and hints at it by saying
>Why waste time with old fashioned data when you can just deal with metadata, and lots of it!