Just want to say I think driehuis' approach strikes exactly the right balance between privacy and corporate interest. It would be even worth writing up as a model policy; I guess the fundamental principle would be to use first bandwidth analysis, then only if necessary traffic analysis, and finally as a very last resort actually looking at the actual user's traffic content. Best, r:b:
"100 XSLT/DOM problems"
This would consists of problems along the lines of, "how do you transform to get...?" Each problem would have DOM as well as XSLT/XPath solutions, with solutions ranging from ugly-and-slow-but-obvious to elegant-and-fast-but-difficult-to-understand. A companion web-site would list even better solutions found later, and additional problems for the 2nd edition "200 XSLT/DOM problems". The problems would NOT be worked case studies that go on for pages; each problem can be stated in a quarter of a page or less.
"Hiding Cryptographic Keys"
There are quite a few books on cryptography now for different operating systems, e.g. for Java and Visual Basic. None of them treat what is fundamentally a non-cryptographic problem: how to hide your keys. If you've gotten the MS or Java Cryptoapi to work and have encrypted all your clients' credit card numbers with a single key (that you have to use frequently for e.g. repeat purchases), how do you hide that key from attackers? You can't encrypt it -- you'll just end up with a new, different key to hide. Cryptographic key hiding is a non-cryptographic computer security problem that will vary from OS to OS and application to application. It starkly illustrates the principle that cryptography (for mere encryption) alone cannot protect your secrets, it can only make them much smaller (by reducing them to a 128 bit key). That secret still has to be protected, but how? As far as I know, no books on this problem exist (for programmers); but without it, cryptography is close to useless for (at least) data-storage security problems. (The problem does not apply to data-transmission attacks, at least insofar as the attacks are only on the channel, not the end-points.)
"Protocols for Everyday Computer Security Problems"
In Schneier's land-mark "Applied Cryptography," numerous cryptographic protocols are described with simple examples of where to apply them. He also makes clear that inventing your own protocol is as silly as inventing your own cryptographic algorithm. But in practice, most programmers inadvertantly end up inventing their own protocols as part of the security solutions they design. (These may or may not use cryptography, but typically do.) This book would present a number of typical scenarios -- for example, a dot com that accepts credit cards, and has a 3rd party customer service operation at geographically distant points with access to the information -- and solutions that adhere completely to established protocols. Of course, it would contain examples of good-looking solutions that are bad because they use ad-hoc protocols; breaks in them would be illustrated as well.
What if the rented software doesn't even reside on the purchaser's servers, but is run instead (e.g. via SOAP) from the manufacturer's server farm? Here not just a key, but most of the code is off-site. This is Microsoft's vision for the next version of Office, and for software in general.
In this case, if the company goes under, there seems to me to be no alternative to switching to new software. One nasty result: businesses will only rent from established companies, not startups. Because of the startup goes under, its customers cannot chug along until they are ready to switch to a new product: they well have to switch almost immediately, at exorbitant costs of retraining etc.
I downloaded it and installed it on Win2K after reading this. It does a terrible job of display: compare www.cvillemovies.com and www.cryptovb.com in it to IE5, and you'll see. It doesn't seem to use the CSS. Also, there is no feedback about errors to the user: you can't tell whether you are in edit mode or not. Type in an URL without http:// and press enter, and nothing happens...eventually you notice a tiny message in the bottom left hand corner, you guess that you have to add http:// to make it work.
With poor CSS support and poor feedback, this browser is unlikely to succeed, even as an evaluation tool of new technologies.
Slashdot Mirror
This article from Bruce Schneier contains the advice you are looking for:
l #c ipherdesign
http://www.counterpane.com/crypto-gram-9810.htm
Just want to say I think driehuis' approach strikes exactly the right balance between privacy and corporate interest. It would be even worth writing up as a model policy; I guess the fundamental principle would be to use first bandwidth analysis, then only if necessary traffic analysis, and finally as a very last resort actually looking at the actual user's traffic content.
Best,
r:b:
"100 XSLT/DOM problems" This would consists of problems along the lines of, "how do you transform to get...?" Each problem would have DOM as well as XSLT/XPath solutions, with solutions ranging from ugly-and-slow-but-obvious to elegant-and-fast-but-difficult-to-understand. A companion web-site would list even better solutions found later, and additional problems for the 2nd edition "200 XSLT/DOM problems".
The problems would NOT be worked case studies that go on for pages; each problem can be stated in a quarter of a page or less.
"Hiding Cryptographic Keys" There are quite a few books on cryptography now for different operating systems, e.g. for Java and Visual Basic. None of them treat what is fundamentally a non-cryptographic problem: how to hide your keys. If you've gotten the MS or Java Cryptoapi to work and have encrypted all your clients' credit card numbers with a single key (that you have to use frequently for e.g. repeat purchases), how do you hide that key from attackers? You can't encrypt it -- you'll just end up with a new, different key to hide. Cryptographic key hiding is a non-cryptographic computer security problem that will vary from OS to OS and application to application. It starkly illustrates the principle that cryptography (for mere encryption) alone cannot protect your secrets, it can only make them much smaller (by reducing them to a 128 bit key). That secret still has to be protected, but how? As far as I know, no books on this problem exist (for programmers); but without it, cryptography is close to useless for (at least) data-storage security problems. (The problem does not apply to data-transmission attacks, at least insofar as the attacks are only on the channel, not the end-points.)
"Protocols for Everyday Computer Security Problems"
In Schneier's land-mark "Applied Cryptography," numerous cryptographic protocols are described with simple examples of where to apply them. He also makes clear that inventing your own protocol is as silly as inventing your own cryptographic algorithm. But in practice, most programmers inadvertantly end up inventing their own protocols as part of the security solutions they design. (These may or may not use cryptography, but typically do.) This book would present a number of typical scenarios -- for example, a dot com that accepts credit cards, and has a 3rd party customer service operation at geographically distant points with access to the information -- and solutions that adhere completely to established protocols. Of course, it would contain examples of good-looking solutions that are bad because they use ad-hoc protocols; breaks in them would be illustrated as well.
Windows 2000 has an equivalent of the keychain, the DPAPI, documented at http://msdn.microsoft.com/library/psdk/crypto/cryp toref1_0lwh.htm.
Windows NT utilized a third party package to provide similar capabilities, the PStoreAPI.
Richard Bondi
What if the rented software doesn't even reside on the purchaser's servers, but is run instead (e.g. via SOAP) from the manufacturer's server farm? Here not just a key, but most of the code is off-site. This is Microsoft's vision for the next version of Office, and for software in general.
In this case, if the company goes under, there seems to me to be no alternative to switching to new software. One nasty result: businesses will only rent from established companies, not startups. Because of the startup goes under, its customers cannot chug along until they are ready to switch to a new product: they well have to switch almost immediately, at exorbitant costs of retraining etc.
I downloaded it and installed it on Win2K after reading this. It does a terrible job of display: compare www.cvillemovies.com and www.cryptovb.com in it to IE5, and you'll see. It doesn't seem to use the CSS. Also, there is no feedback about errors to the user: you can't tell whether you are in edit mode or not. Type in an URL without http:// and press enter, and nothing happens...eventually you notice a tiny message in the bottom left hand corner, you guess that you have to add http:// to make it work.
With poor CSS support and poor feedback, this browser is unlikely to succeed, even as an evaluation tool of new technologies.