You can make a hash out of a file

>you can make a hash out of a file
>changing one single bit modifies the entire hash

Why can't we make files out of hashes? 99.999999999999999999999999999999999999% compression when?

Other urls found in this thread:

github.com/philipl/pifs
youtube.com/watch?v=dQw4w9WgXcQ
mofowebsite6-a-z2.com/resource?in=a
mofowebsite6-a-z2.com/resource?in=b
mofowebsite6-a-z2.com/resource?in=c
twitter.com/SFWRedditGifs

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?

Because its only an identifer, not the actual data

Kill yourself, you fucking mong.

avg Sup Forums poster

This is actually decent bait.

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

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. github.com/philipl/pifs

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

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

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.

Shit user finally a use for my raspberry pi. Thanks!

@59621408

*yawn*

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

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.)

>(You)

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

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

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

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.

>hash is just signature to verify data integrity

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

:^D

Hashing is different because it's one to one

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.

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

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

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

fucking hash collisions, man

damn google you failed me today

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.

It shows

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.

...

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.

>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?

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

>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.

I think you got that backwards

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.

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.

>hashing with md5
we weas romanz and shee

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.

>hitler did nothing wrong
that's how you sound

He does sound correct.

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

ahh the nostalga of working minimum wage and waking up late

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

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

>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.

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

If it's not then, well, woopsies.

md5 is insecure, has been for years

What you are talking about is the same as a youtube url 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.

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

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

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

you are an idiot

>Not using salt

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

Although as 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.

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

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.

>To collision attacks
which is a really big deal

thanks for confirming once again

>not using pepper

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.

But completely irrelevant to password hashing.

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

Woops I just got baited

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

>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.

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

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.

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

And why is that?

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

Pigeonhole principle.

/thread

Shitposting at its finest

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

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.)

>Hey this hash is unintentionally broken and can be reversed

Sup Forums 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

>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.

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.

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.

>doesn't understanding that hashing is one way

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

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

>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).

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.

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.

>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.

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

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

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!

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

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

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.

rough user.... 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

Elaborate.

>Jokes on you though. I can store all data using pi. 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!