Cryptography offers us many things - not just the ability to lock up secrets that can only be decoded if we know some secret password. Using the processes of hashing, encoding and decoding, we've been brought capabilities such as digital signatures, network secrecy and non-shared key authentication. I was thinking about one particular capability offered by our cryptography geniuses - the use of hashing algorithms to derive secret keys over a given number of cycles without an easy way to determine the solution without actually performing the calculations over that number of cycles. Wow - that sounds like it's going to get complicated...Let's back up and take a look at just what a key derivation function is.
In essence, what these protocols do is come up with a determinate sequence of pseudo-random numbers by performing a set of specific calculations over and over (you set the number of repetitions). By feeding the function a pass-phase, it will blend that pass-phrase into a messy sequence of numbers that supposedly can not be reverse-engineered through any other means other than using the same blending process with the exact same pass-phrase over the same number of cycles. There's different versions of this, bcrypt, PBKDF2 and scrypt, with scrypt being the more modern of the three - designed to not only take repetition into account, but also arbitrary memory usage, which helps you to keep function costs higher by requiring additional hardware costs for parallel attacks.
What struck me today is that this function can essentially be used as a time-lock. To the analogies!!! You walk into a bank and go to hold up the teller - you might get out of the bank with $1,000 - $2,000...hardly worth the risk. Why don't you rob the safe in the back that holds all of the money? Because it has a time-lock on it. It can probably only be unlocked by the bank manager after putting in the combination and waiting for an hour for the safe to open. If you're robbing a bank, your time frame is a lot shorter than an hour. It raises the risk of being caught and the bank knows this - which is why they use time locks. The longer it takes you, the heavier the risk side of your risk/reward see-saw.
What if people implemented time-locks for high-risk transactions in the automation of business transactions. The risk of a transaction could be a measurement of how long transactions would need to take. Time locks would be implemented in such a way that the verification of the transactions would utilize key derivation functions to complete, with half of the compute time being taken by the sender, and half the compute time being taken by the receiver.
Transferring $10 to your wife's account? No problem, sir, take but a second..
Oh, you want to transfer $200,000 to a random account number in the Grand Cayman Islands? Yes, sir - we can do that for you - the transaction will begin now, and the transfer will complete in 12 hours. No, sir, the receiving party will not credit the amount until both sides reach the agreed upon key for the transaction. The transaction will show as 'pending' until it completes or is aborted.
As computing time/resources get cheaper, validation time can be kept in line with the risk, requiring specific amounts of resources (cycles, processes, memory) to perform the transaction. Resource costs would have to be passed on to customers as part of transfer fees - time increases would be enforceable at the interface level, since communication of the transaction verification could not be done without the derived key, enforced by a protocol standard.
Now for the devil's advocacy - This would have a negative impact on customers performing high-risk transactions. It would probably never make it past lobbying organizations, and people who regularly pass around large sums of money would find some other way of performing wire transfers to get around the limitations. Also, time-locks could be implemented without even using these processes if banks REALLY cared about the risks of risky automated transactions, through simple business rules and agreed upon timelines and risk limits. So- just another random rambling....
Post a Comment