The worst-case baseline benefit of using Scraps

So let’s estimate the time it takes an Interceptor to retrieve our secret key in the most nightmarish of scenarios where she knows everything but the actual winning combo to the Lotteries. Suppose that somehow she’s even aware of that there are 10 valid Scraps to look for in each bunch. (However, we do so solely for the purpose of simplifying calculations as in reality it would be an unfathomable misfortune for that to happen to anyone.)

Since out of all the 100 Scraps, the Interceptor has to pick the 10 valid ones and line them up in the correct order, the number of arrangements she has to try out is (100 choose 10) · 10!. But because this figure pertains only to one of the sites while we have two of those, this number ought to be squared (and also doubled). Essentially what this means is that we’ve got not one but two Lotteries in a row to win pushing all the combinations up to about 7.89 · 10 ³⁹.

Also, the Interceptor has one million of the World’s most powerful (as of 2013) supercomputers at her disposal, each one of them clocking at 33.86 PetaFlops. Considering that a single trial of password at the very least takes a 1,000 Flops, she can try out 33.86 · 10 ¹⁵ · 10 ⁶ / 10 ³ = 3.386 · 10 ¹⁹ combos each second. We supposed very unrealistically that it takes zero time to put together the Scraps for any trial and assume that the only thing that requires time is the trial of the single password for each collection of Scraps. Again, this is overly optimistic for the Interceptor, and thus a glum prospect for us.

This way, we gather that the time it takes such a formidable Interceptor in such a hellish scenario to retrieve the key for sure is 7,385 billion years that is indeed the age of the Universe 536.27 times over.

Pretty impressive especially when considering that this actually happens to be the worst-case baseline benefit that using Scraps gives us. Everything that doesn’t go wrong — or any trick that we might adopt to use for that matter — only improves on this.

Tips for implementation

Encouraging as it might feel to see how well this Scrap of a system holds up against such a nightmarish scenario, we might still want to add further layers of security.

A couple of hints to do that:

• First and foremost: By all means, use a strong password to encrypt your original key! (We used “123456” in the example solely for a dramatic effect.)
• Use entirely unrelated user accounts across distinct sites you store your Scraps at. This makes it harder for providers (by matching the registered email addresses, user names, passwords) to identify you, and even forces them to carry out a full-blown search in cooperation with one another. If they cannot discern the (because they are stored with different accounts) owner of the matching collections of Scraps, this becomes another layer of security in the form of a haystack on a higher level where a certain Scrap corresponds to a collection of Scraps. Speaking of which, to make it technically harder to trace your user accounts:
• Make your Scraps hard to track down upon downloading. For instance, you can have them make some crazy random detours with the combination of handy Tor-based tools.
• “Dilute” the Scraps: add lots of other Decoys on top of the existing ones, and then encode the file names of all the Scraps to “spread them out” to the whole range. By adding, say, 900 extra Decoys, we can push the potential Scraps up to a 1000 on each site in our example (990 Decoys instead of the 90 this time around). This makes the interceptor’s outlook on winning the Lottery even more dismal while keeping the winning sequence for us to remember the same, and in effect, easy (remembering 10 numbers each falling in the range 1..100, instead that of 1..1000).
• For convenience, you might abandon the need of memorizing number-sequences for locating valid Scraps among the Decoys. Instead, with the help of some smart transcoding method, use something easier to remember, something more “passwordish”.