I want to explore the possible reversibility of hash's using IPFS, or rather of using IPFS as a hash-archive to exploit hash-based security in certain ways. The following wall of text (and I do apologize for that) is also here, since I wrote this in advance trying to outline my thoughts - https://ghostbin.com/paste/xsdj7
:: Reversing The 'Irreversible' Hash ::
--
Some general points on IPFS:
• IPFS uses self-signing multihash; this means all major hash algo's (and hex, base32, 58, & 64 variants) are recognized - https://github.com/multiformats/multihash
• You can generate the SHA1, SHA256, or SHA512 hash of a file in your terminal and pipe it to IPFS, telling it to crawl for that hash till it finds it.
• You can see if any peers are hosting a file with: $ ipfs dht findprovs [hash]
• Most files do not exist yet on IPFS, but since IPFS is essentially an infinitely-scalable hash-archive, and it's growing exponentially right now, we can expect a significant minority of files to exist on it soon.
--
Steganography with IPFS:
You can use IPFS to hide messages so long as the hash was generated and archived on IPFS. The plaintext gets hashed and then you send the hash as the direct message. You can also use this to hide images or video. Any type of file can be hosted on IPFS; finding and accessing the file is arbitrary if you know the hash.
There are obvious additional implementations of steganographic content this way, but as far as I know, there is currently no such thing as hash-based steganography since hash's are not supposed to be reversible. So unless I am unaware of something obvious, this is a first.
--
Password cracking with IPFS:
Generating hash tables from string-permutations in order to break into database's whose user's passwords were hashed would normally take a lot of processing power and time. Even with rainbow tables the total possible lists are terabytes (or petabytes) of information.
With IPFS, all you would have to do is generate a complete lookup table once and make sure it gets distributed around IPFS. Exabytes of possible passwords can be stored off-site, and things like FileCoin will ensure people are willing to host these IPFS-based archives. All future hashes of passwords could be instantly looked up and their corresponding plaintexts returned with them.
To keep this feasible, you would cap the hash generation to password permutations 32 characters long (or whatever arbitrary amount you decide on). This does not get everything, really strong passwords would stay secure, but it will get you the disproportionate majority of passwords used for every site past, present, or future.
Something, something, ipso facto, now you have access to billions of dollars worth of assets, agreements, conversations, etcetera. Yea it would take a really long time to generate the complete lookup table, and yea it would cost a lot of money (millions?) to ensure it's being mirrored around IPFS, but the ROI here easily makes up for this, and this would be a permanent archive that is incredibly difficult to censor or take down.
--
Why this can't be used for cracking private keys in asymmetric-key protocols:
If IPFS can be used as a giant hash table archive, then you could just as easily use it as a private-key archive, right? E.g. we could look at Bitcoin addresses. You can generate all public and private key pairs already through services like https://directory.io/ and run tests with https://gobittest.appspot.com/, but generating the /full/ list is infeasible for any network. Even if IPFS becomes as large as the web there isn't enough storage space on all the disks of the world to hold even a substantial minority percentage of the address pairs.
If there was enough space on IPFS to hold 0.1% of the key-pairs at a time, then you could run an exploit that chugs through that fraction of a percent at a time, only saving keys whose public addresses have coinage sitting on them, right?
Processing all this is infeasible still. Short lists are arbitrary to generate, but long lists would be limited by the speed at which you could check the addresses and have the relevant ones uploaded and mirrored through IPFS, which would be incredibly slow. Even without having to upload to IPFS, it would still take thousands of years to generate the key pairs in the first place, let alone perform any actions with them all.
Unless there is a way to make the linked directory reverse-searchable so it wasn't ordered by private keys but also public keys, then there is no feasible way to find key-pairs.
--
All that being said, this was more of an outline on the potential of IPFS than of the insecurities of hashcodes. If someone has beaten me to all this already, or if I'm missing something obvious and devastating, I would love to be corrected, thanks.