The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Patrick O'Keefe) writes: > We've been moving towards secure data transmissions with business > partners (with testing starting in about a week) but nobody had > checked what we could do to lessen the effect encryption would > have on our processors. the internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet required encryption on all traffic that left corporate facility (like inter-site traffic). when most places were doing 9.6kbit, we were working on full-duplex T1 ... and looking at associated problems in HSDT project http://www.garlic.com/~lynn/subnetwork.html#hsdt old email reference looking at problem supporting full duplex T1 on 3081 http://www.garlic.com/~lynn/2006n.html#email841115 in this post discussing encryption technology http://www.garlic.com/~lynn/2006n.html#36 The very first text editor part of the effort was looking at being able to move past hardware link encryptors as solution to the opportunities (which was the default state-of-the-art at the time). other old crypto related email http://www.garlic.com/~lynn/lhwemail.html#crypto included old email reference to a non-certificate-based public key infrastructure for more secure communication over the network http://www.garlic.com/~lynn/2006w.html#email810515 in this post: http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network other recent posts to discontinuity between the hsdt project (doing T1 and faster interconnects) while other operations were still looking at 9.6kbit with a little more to ("high-speed") 56kbit http://www.garlic.com/~lynn/2007q.html#45 Are there tasks that don't play by WLM's rules for other old topic drift ... we had been called to come in and consult with this small client/server startup that wanted to do payments on their server http://www.garlic.com/~lynn/subnetwork.html#gateway and they had this technology they invented called SSL that they wanted to use as part of the implementation. we had to do some end-to-end studies looking at how to apply the technology to the business processes some related posts http://www.garlic.com/~lynn/subpubkey.html#sslcerts afterwards we participated in the x9a10 financial standard working group that in the mid-90s had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments. the result was the x9.59 financial standard http://www.garlic.com/~lynn/x959.html#x959 x9.59 took a slightly different approach, in part because of detailed end-to-end threat and vulnerability analysis involving retail payments, basically identifying significant authentication vulnerability which then led to requirements for hiding transaction information ... as countermeasure to crooks obtaining the information and being able to perform fraudulent transactions. the observation was that the transaction information was needed at a large number of different processes, potentially occuring over extended period of time ... and as a result, even if the planet was buried under miles of crypto ... it still wouldn't prevent information leakage. the x9.59 financial standard approach was then to fix the underlying weakness, lack of strong authentication ... which also then eliminated needing to hide the transaction information from crooks (since the information was useless w/o the proper authentication). some of this is discussed in the posts concerning the naked transaction metaphor http://www.garlic.com/~lynn/subintegrity.html#payments ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
