On 13 November 2015 at 02:27, Timothy Sipples <sipp...@sg.ibm.com> wrote:
> This thread is a microcosm of the sort of considerations professional > developers *ought* to have, to at least strive to write *enduring* code -- > and preferably not write code at all unless really required since custom > code itself has an inherent brittleness to it. I don't disagree with some of your general statements, Timothy, but really this thread is a microcosm of general considerations only by virtue of your posts to it. The OP is faced with a quite specific problem: > This string arrives from a browser, encrypted using RSA: > > x..xx<PAN>pppppppppppppppp</PAN><KEY>kkkkkkkkkkkkkkkk</KEY> > > I decrypted the string using the private key and converted it from ASCII to > EBCDIC without any problem. > > The <KEY> tag is a 3DES symmetric key, specified as sixteen hexadecimal > digits, which has been generated by > the browser for the server (z/OS) to encrypt the response. The response is a > short 8 byte extract of confidential > details relating to the bank card identified by the PAN. I already have the > response converted to ASCII ready to be > encrypted using the browser supplied encryption key. But how to encrypt it ? I hardly think this calls for a grand re-architecting of the company's whole system, nor do I imagine that the OP has a mandate to do so. The problem is small, well specified, and the solution clearly has to fit the existing data and methods. It is certainly arguable that calling ICSF rather than using a single machine instruction would allow for different algorithms, and perhaps even take advantage of future IBM performance improvements, but there is no place in the incoming data for a key type, and even if there was, its mapping to arguments on an ICSF call is no more straightforward than its mapping to an argument on the KM instruction. And equally important, there is no provision for anything but clear key processing in the problem description. As for your claim that "custom code itself has an inherent brittleness to it", there is no fundamental reason that code written by, say, a bank is more brittle than that written by, say, IBM. Each enterprise presumably employs suitably trained, responsible, and well managed technical people to write code to address business problems. Deeming the bank's code to be "custom", but IBM's (or other vendors') to be "standard", as I infer to be what you are saying, is unsupported by fact. Build vs buy is a business decision, best based on all the facts rather than hard-coding the answer as "never build; always buy". > These are the sorts of > considerations I try to imagine in my line of work, to imagine how the > design will be flexed and evolve over time. I'm sure it's an interesting line of work. > I think it's worth spending at least a little time worrying about such > issues, because then it's more > likely that one creates great, durable, timeless work. I don't disagree at all. But not every small technical problem justifies more than a small technical solution. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
