Dr. Dobb's Journal July 2003
Dear DDJ,
While the protocol Daniel Fremberg presented in his article "The Mithra Authentication Protocol" (DDJ, May 2003) is based on some good ideas, I see a problematic hole in it. Using the IP addresses for authenticating client and server means that it is unable to detect an MITM attack using a device that behaves like an Ethernet bridge. Using such a device, packets can be captured, diverted, and modified, without changing the source and destination IP addresses. In that case, the protocol falls back to simply being equivalent to hashing the password, some known content, and the nonce. In general, if an MITM attack can be launched, then the IP addresses of the client and server are almost certainly not trustworthy. Using the IP addresses is equivalent to trusting the integrity of the network path to detect a compromise of that path: Hence, why proof of secret knowledge is generally used to detect and prevent MITM attacks, as they depend on integrity of the endpoints and not the path between them.
Matthew Gabeler-Lee
msg2@po.cwru.edu
Daniel responds: Thank you for your interest in Mithra, Matthew. Mithra does not prevent or detect if someone captures the messages; anyone can do that. In fact, Mithra readily assumes that this is taking place. If the Ethernet bridge is modifying the message, it will be detected when the authenticators are compared. I do, however, fully agree with you that using the IP addresses is equivalent to trusting the integrity of the network path. In a world where IP networks and protocols are ubiquitous and the (unsecure) design of TCP being how it is, an IP address is the "best" (or only) identifier a network participant can rely on. I realize, of course, that an IP address can be considered untrustworthy given its nature. Be that as it may, Mithra is not restricted to only use IP addresses. In the future, perhaps other network identifiers will emerge that will allow a more robust application of Mithra.
Dear DDJ,
In regards to Kurt Guntheroth's letter in the May 2003 issue of DDJ, I don't think "corporations are required by law to seek the highest return on their investor's capital." I believe it is normally the investors who are assigned that lamentably difficult task. Otherwise, to name one example, there would be no Ben & Jerry's.
The rest of Kurt's letter advocating IT unionization I couldn't approve of more. If Kurt can gather some like-minded souls, we can look forward to considerable amusement in the possibly dreary months ahead. Actually, I was peripherally involved years ago when the New York newspaper and typesetting business received the kind ministrations of the typographical union. The union was very, very strong, the industry wound up very weak, and thousands of ITU members had very generous retirements. The technology they fought—cheapo computer-based offset printing—is now totally dominant. On the other hand, it took considerably longer for New Yorkers to get hold of their waterfront, as literally generations of politically powerful longshoremen fought any tampering with "the docks." Conceivably, Kurt's union could be equally successful.
J.G. Owen
owen_labs@worldnet.att.net
Dear DDJ,
In "The SquareList Data Structure" (DDJ, May 2003), Mark Sams described the data structure which offers O(sqrt(n)) time to both insert elements in and delete elements from a totally ordered set, and O(1) time to retrieve the minimum and maximum elements.
The double-ended priority queue, or "priority deque," is a similar data structure (in terms of functionality) and is only a little more complex to program than a SquareList, but offers much better performance: O(log(n)) to insert an element, O(log(n)) to delete the maximum or minimum element, and O(1) to retrieve the maximum and minimum elements. To appreciate the difference between O(sqrt(n)) and O(log(n)), consider that sqrt(10000) is 100, while log_10(10000) is 4 and log_2(10000) is still only 13.
For more information, see Atkinson et al., "Min-Max Heaps and Generalized Priority Queues," Communications of the ACM (October 1986). A Java implementation of the Atkinson algorithm can be found at http://www.alexandria.ucsb.edu/~gjanee/archive/1999/PriorityDeque.java.
Gregory A. Janie
gjanee@alexandria.ucsb.edu
Dear DDJ,
The article "XML Data Binding," by Eldon Metz and Allen Brookes (DDJ, March 2003) really only shows one side of XML binding—generating classes from pre-existing XML Schema/DTDs. There are lots of tools that implement this functionality including JAXB (http://java.sun.com/xml/jaxb/), and BreezeFactor's Breeze XML product (http://www.breezefactor.com/), as well as some open-source tools like JaxMe (http://jaxme.sourceforge.net/) and the already mentioned open-source Castor.
From my (and colleagues') observations, most development shops are usually the other way around—they already have Java code (or code in some other language) that needs to be serialized to/from XML. While it's very easy to implement a tool that generates a class from DTDs or XML Schema, it's very hard to go the other way, from Java/other source to XML binding functions. That's just one of the reasons why there are so many implementations of the Schema/DTD to class tools and not many that work the other way around. "XML Data Binding" mentions some difficulties with serializing preexisting classes, but Eldon and Allen failed to research any tools that provide this capability and devoted little space to this problem in the article.
There are at least two tools that provide this capability that I'm aware of (from source to XML binding functions): The Mind Electric's Electric XML (http://www.themindelectric.com/exml/), and the open-source XMLOatmeal project (http://xmloatmeal.sourceforge.net/).
Mike Moretti
XMLOatmeal Project Lead/Developer
mikemoretti@users.sourceforge.net
DDJ