In terms of definitions for FC, applying crypto to banking and finance doesn't work. Mostly because those doors are simply closed to us, but also because that's simply not how it is done. And this brings us to the big difference between Bob's view and FC7.
In Bob's view, we use crypto on anything that's important. Valuable - which is much more open than, say, the 'bank' view. But this is still bottom-up thinking and it is in the implicit assumption of crypto that the trouble lies.
Applications are driven top down. That means, we start from the application, develop its requirements and then construct the application by looking downwards to successively more detailed and more technical layers. Of course, we bounce up and down and around all the time, but the core process is tied to the application, and its proxy, the requirements. The requirements drive downwards, and the APIs drive upwards.
Which means that the application drives the crypto, not the other way around. Hence it follows that FC might include some crypto, or it might not - it all depends on the app! In contrast, if we assume crypto from the beginning, we're building inventions looking for a market, not solving real world problems.
This is at heart one of the major design failures in many systems. For example, PKI/SSL/HTTPS assumed crypto, and assumed the crypto had to be perfect. Now we've got phishing - thanks guys. DigiCash is the same: start from an admittedly wonderful formula, and build a money system around it. Conventional and accepted systems building practices have it that this methodology won't work, and it didn't for DigiCash. Another example is digital signatures. Are we seeing the pattern here? Assume we are using digital signatures. Further assume they have to be the same as pen&ink signatures.... Build a system out of that! Oops.
Any systems methodology keeps an open mind on the technologies used, and that's how it is with FC7. Unlike the other definitions, it doesn't apply crypto, it starts with the application - which we call the finance layer - and then drives down. Because we *include* crypto as the last layer, and because we like crypto and know it very well, chances are there'll be a good component of it. But don't stake your rep on that; if we can get away with just using a grab bag of big random numbers, why wouldn't we?
And this is where FC7 differs from Bob H's view. The process remains security-oriented in nature. The people doing it are all steeped in crypto, we all love to add in more crypto if we can possibly justify it. But the goal we drive for is the goal of an application and our solution is fundamentally measured on meeting that goal; Indeed, elegance is not found in sexy formulas, but in how little crypto is included to meet that goal, and how precisely it is placed.
The good news about FC7 is it is a darn sight more powerful than either the 'important' view, and a darn sight more interesting than the banking view. You can build anything this way - just start with an 'important' application (using Bob's term) and lay our your requirements. Then build down.
Try it - it's fun. There's nothing more satisfying than starting with a great financially motivated idea, and then building it down through the layers until you have a cohesive, end-to-end financial cryptography architecture. It's so much fun I really shouldn't share it!
Posted by iang at March 2, 2005 01:55 AM | TrackBackFundamental problems
-you're assuming a structured software/app development approach, which is not feasible in the world outside powerpoint
-PKI/HTTPS are not bad in and of themselves. Individual implementations are bad.
-Lack of user education: there's still a fundamental disparity between what users are prepared to learn in the "real world" and what they're prepared to learn about computer use. Maybe the message is presented wrongly, maybe the consequences were never serious enough, but mollycoddling the plebs by placing all blame squarely on an evolving medium like applied crypto is wrong.
-John
Posted by: JMS at March 3, 2005 08:06 AM