Quote from: adam3us on October 16, 2013, 12:48:33 PM

Quote from: adam3us on October 16, 2013, 09:52:18 AM

If the address where the $80m is stashed, or some of them are identifiable, they are effectively tainted as belonging to DPR / Ulbricht.

When he's finally free in 15yrs or whatever DPR maybe richer than Bill Gates, but with a lot of tainted coins. Satoshi's coins are also tainted (not in a negative way but due to the linking bug).

Quote from: gmaxwell

Lot of good they're currently doing him (or likely to do him ever considering the charges). I'd really rather not participate in a discussion where someone with charges like this is held up as exemplar, as it's too easy to go off on a insane tangent.

I dont think it matters so much the actual scenario the point is to find ways to improve bitcoin security (and security of data & auth keys generally). As Ed Felten observed recently, no its not a good idea for judges to start thinking because they can issue subpoenas that internet physics and software architects somehow owes them data in a subpoenable form. The reason is the design is the same whether you are protecting against theft, blackmail, extortion, corrupt insider, or subpoena - its all the same thing from a technology perspective.

https://freedom-to-tinker.com/blog/felten/silk-road-lavabit-and-the-limits-of-crypto/

Clearly whatever you think of the war on drugs, and personally I am against drug taking but also against governments in a free country removing individuals freedom to choose, DPR if the charges arent made up apparently tried to have someone assassinated which obviously is very uncool.

Anyway sometimes its fun to think about and articulate security problems in a james-bond-esque setting, over the equivalent but boring dining-cryptographers setting etc, but the techniques are the same if its a wealthy individual safe-guarding their money from extortion, or a normal level wealth protecting their bitcoin from theft physical or virtual.

Adam

Ha, it seems to me that cryptography was actually established to protect against evil villains, not your Grandma or roommate, who most likely don't even know how to view your files with hidden attributes. Wink

Now back to something more on topic, I wonder if it makes sense to imagine some key-stretching function f, which for different values of x, would take vastly different time to find y=f(x) or y=f(x,s) if we add a salt, like for x1 it would take 1 nanosecond to execute the calculation, but for x2 it would take 1 minute. The disparity in the time of computation must be so large that a small percentage of "tough" numbers will take up most of the computation time. With such a function at hand, and a statistical knowledge of the distribution of the "tough" numbers x_d, I can obtain an estimation of the time it takes to scan across a randomly selected range of numbers to find a "softie" number, which should contain a fair bit of entropy, the total scanning time/initial stretched key generation time should be long enough yet tolerable(like 1 day or so), while the stretched-key creation time with the initial key already known much shorter as the chosen x is a softie. Now for an attacker who has no information whatsoever about the seeding key being used, it will take him an infeasibly long time to brute-force to the number we use, due to those "tough" numbers on his way, as he has to start from zero and scan through a much larger range of numbers than us. I naively assume that if such a function can be created, it could provide us with a reasonable key initialisation time(hours or days), short key reconstruction time with seeding key known(seconds), and infeasibly long brute-forcing time, and relatively benign ket/salt entropy requirement.

Example: Let's say we have 2^64 elements to try, dividing into 2^32 sets, testing all 2^32 elements in one set will take approximately 1 day according to some statistics, with 99% of the time being taken up by testing against just 1% of the tough elements, so that instead of having a brute-forcing/normal enhanced key creation time of about 2^63, we could, hypotehtically make it much longer without increasing password complexity.