| The Ultimate Business Machine Technology, business And, not least, about by: Bernard Teo
|
Sat 25 Jun 2005 WebServer Monitor 1.0.8 ReleasedCategory : Technology/WebMon108.txt While WebServer Monitor itself will run on either Panther or Tiger, there is a bug when the web server is on Tiger. WebServer Monitor doesn't SSH (login) into the remote (Tiger) machine correctly and therefore cannot set up its server log format properly. This release fixes that bug. Also I've re-arranged the Navigation menu, changed its keyboard short-cuts, and added a menu item to revert to the last search done on the Search History List (in the Search Field). Hopefully, these will make it even easier to move around the log data. WebServer Monitor can be downloaded here. Stay Foolish. Because God Rewards Fools.Category : Commentary/stayFoolish.txt The trio of Martin Hellman, Whitfield Diffie and Ralph Merkle had been the first to find an answer to the key distribution problem of cryptography (see previous post). Or, at least, a conceptual answer, because they were followed by another trio - whose initials made out R, S, and A - who actually supplied an implementable solution. That's why PKI encryption is also known as RSA encryption today. But, anyway, here's a quote from Martin Hellman, from Simon Singh's book : "The way to get to the top of the heap in terms of developing original research is to be a fool, because only fools keep trying. You have idea number 1, you get excited, and it flops. Then you have idea number 2, you get excited, and it flops. Then you have idea number 99, you get excited, and it flops. Only a fool would be excited by the 100th idea, but it might take 100 ideas before one really pays off. Unless you're foolish enough to be continually excited, you won't have the motivation, you won't have the energy to carry it through. God rewards fools." Remember the end of Steve Jobs' Stanford commencement speech where he said, "Stay Hungry. Stay Foolish"? Because God rewards fools. Alice and Bob Go PublicCategory : Commentary/PKI.txt I was reading Simon Singh's "The Code Book - The Science of Secrecy from Ancient Egypt to Quantum Cryptography" and this is the first time I really understand this concept called the Public Key Infrastructure (PKI) which we use in mail and web servers when we "turn on SSL". If you start with Simon Singh, then move on to Steven Levy's "Crypto", and then reach David Kahn's "The Codebreakers", you should be able to get a very good grounding as to why having an understanding of this dismal science is really so important to running a business in our Internet age. This is the first time I've found someone who could draw a meaningful picture around PKI - i.e., the problem it was meant to solve, how it solved it, and why that's significant. And so I'll quote that part of the book that created that Eureka moment and encourage you to read it, too. If you're concerned about running a business on the 'Net, this will be a meaningful journey : "The whole problem of key distribution is a classic catch-22. If two people want to exchange a secret message over the phone, the sender must encrypt it. To encrypt the secret message the sender must use a key, which is itself a secret, so then there is the problem of transmitting the secret key to the receiver in order to transmit the secret message. In short, before two people can exchange a secret (an encrypted message) they must already share a secret (the key)." "When thinking about the problem of key distribution, it is helpful to consider Alice, Bob and Eve, three fictional characters who have become the industry standard for discussions about cryptography. In a typical situation, Alice wants to send a message to Bob, or vice versa, and Eve is trying to eavesdrop. If Alice is sending private messages to Bob she will encrypt each one before sending it, using a separate key each time. Alice is continually faced with the problem of key distribution because she has to convey the keys to Bob securely, otherwise he cannot decrypt the messages. One way to solve the problem is for Alice and Bob to meet up once a week and exchange enough keys to cover the messages that might be sent during the next seven days. Exchanging keys in person is certainly secure, but it is inconvenient, and if either Alice or Bob is taken ill the system breaks down. Alternatively, Alice and Bob could hire couriers, which would be less secure and more expensive, but at least they will have delegated some of the work. Either way, it seems that the distribution of keys is unavoidable. For two thousand years this was considered an axiom of cryptography - an indisputable truth. However, there is a thought-experiment that seems to defy the axiom." And so the stage is set ... "Imagine that Alice and Bob live in a country where the postal system is completely corrupt, and postal employees will read any unprotected correspondence. Alice wants to send an intensely personal message to Bob. She puts it inside a strongbox, closes it, and secures it with a padlock and key. She puts the padlock box in the post and keeps the key. However, when the box reaches Bob he is unable to open it because he does not have the key. Alice might consider putting the key inside another strongbox, padlocking it and sending it to Bob, but without the key to the second padlock he is unable to open the second box, so he cannot obtain the key that opens the first box. The only way around the problem seems to be for Alice to make a copy of her key and give it to Bob in advance when they meet for coffee. So far, I have just restated the same old problem in a new scenario. Avoiding key distribution seems logically impossible: surely, if Alice wants to lock something in a box so that only Bob can open it, she must give him a copy of the key. Or, in terms of cryptography, if Alice wants to encipher a message so that only Bob can decipher it, she must give him a copy of the key. Key exchange is an inevitable part of encipherment - or is it?" And now the denouement ... "Now picture the following scenario. As before, Alice wants to send an intensely personal message to Bob. Again, she puts her secret message in a strongbox, padlocks it and sends it to Bob. When the box arrives, Bob adds his own padlock and sends the box back to Alice. When Alice receives the box, it is now secured by two padlocks. She removes her own padlock, leaving just Bob's padlock to secure the box. Finally she sends the box back to Bob. And here is the crucial difference: Bob can now open the box because it is secured only with his own padlock - to which he alone has the key." "The implications of this little story are enormous. It demonstrates that a secret message can be securely exchanged between two people without them first exchanging a key. For the first time we have a suggestion that key exchange might not be an inevitable part of cryptography." And so this is the start - having a clear mental model of the basic issues to make the mind more ready to consider a few other possibilities. It takes a couple more steps from here to reach how public key encryption actually works today in our systems. And then one more step to understandiing something called PGP - Pretty Good Privacy. I believe it's going to become very important to learn how to make these things work for us in our businesses. We've already got all these stuff built into our little Macs. All we need is to figure out how to turn them on. Right. The Mac Way. |
Mac@Work
Services running on this server, a Mac Mini running Mac OS X 10.9.2 Mavericks:
all set up using MailServe, WebMon, DNS Enabler, DNS Agent, VPN Enabler, Liya and our SQL installers, all on Mavericks. |
||||||||||||||||||||||||||
