arno...@us.ibm.com (Todd Arnold) writes: > Gee, I've been developing crypto technology for 30+ years that runs in > those environments - so it's certainly news to me that it can't be > done :-)
re: http://www.garlic.com/~lynn/2017c.html#60 [EXTERNAL] ComputerWorld Says: Cobol plays major role in U.S. government breaches http://www.garlic.com/~lynn/2017c.html#61 [EXTERNAL] ComputerWorld Says: Cobol plays major role in U.S. government breaches I had project HSDT that started out dealing with T1. http://www.garlic.com/~lynn/subnetwork.html#hsdt The internal network was larger than arpanet/internet from just about the beginning until sometime mid-80s. A major difference between the internal network and arpanet/internet (besides being larger network) was corporate required all links to be encrypted. http://www.garlic.com/~lynn/subnetwork.html#internalnet One of my problems was that my slowest speed line was 1.5mbites/sec second, or around 300kbytes/sec full-duplex. Turns out that software DES on 3081 ran at 150kbytes/sec per processor. Needed 100% of both 3081 processors dedicated for any software DES encryption. some old crypto email http://www.garlic.com/~lynn/lhwemail.html#crypto so external boxes were required for doing any reasonable amount of encryption. However I hated what I had to pay for T1 link encryptors ... and it was almost impossible to find faster link encryption boxes. As a result, I got involved in doing a box that would support at least 3mbyte/sec and cost less than $100 to build. I got slammed by the corporate crypto products group that it significantly weakened the strength of standard DES standard. It took me three months to figure out how to explain to them what was going on (significantly stronger than DES standard rather than signnificantly weaker). It was a hollow victory ... I was then told that there was only one organization in the world that could use such crypto, I could make as many boxes as I wanted but I had to send all boxes to an address in Maryland. It was when I realized that there are three kinds of crypto in the world, 1) the kind they don't care about, 2) the kind you can't do, 3) the kind you can only do for them. My other conflict with the communication group ... HSDT was having some equipment built on the other side of the pacific. The friday before a trip to the other side of the pacific ... the communication group distributes an announcement for new online discussion group on high speed with the following definition: low-speed: <9.6kbits medium-speed: 19.2kbits high-speed: 56kbits very high-speed: 1.5mbits on Monday morning, in a conference room on the other side of the pacific was the following definitions low-speed: <20mbits medium-speed: 100mbits high-speed: 200-300mbits very high-speed: >600mbits of course, part of the problem was the fastest that the communicaton group controller boxes supported was 56kbits. They had even done a study for the corporate executive committee claiming that customers wouldn't want T1 before the 90s. They had studied customers running "fat pipes" (two or more parallel 56kbit links operating as single logical link) where they found no customers with more than five 56kbit links. What they didn't know (or failed to present) was that typical tariff for six 56kbit links was the same as single T1 link (1.5mbit) ... so customers got real T1 and operated them with non-IBM controller. Upthread I referenced getting roped into doing standard for financial transactions .... transaction information has been involved in the majority of the breaches ... from data breach notification work, past posts http://www.garilc.com/~lynn/submisc.html#data.breach.notification We identified that the information could be reused for fraudulent financial transactions ... so previous transaction information had to be kept confidential and never divulged. However previous transaction information was also required in dozens in business processes at millions of locations around the world. This sets up diametrically opposing requirements ... never divulged and always available ... resulting in the comments that even if the planet was buried under miles of information hiding encryption wouldn't stop information leakage. The standard we came up with eliminated such replay attacks, eliminating crooks motivation for breaches and therefor no need to encrypt/hide the information (the problem was while it was minor tweak to the protocol, it resulted in major hit to vested interests trying to preserve some status quo). I've also pushed the "security proportional to risk" meme (for the financial transaction breach theme). The value of the transaction information to the merchant is profit from the transaction can be a couple dollars (and a few cents to the transaction processor). The value of the information to the crooks is the account balance or credit limit. As a results, the crooks can afford to spend 100 times more on attacking than merchants can afford spending on defending. recent posts http://www.garlic.com/~lynn/submisc.html#security.proportional.to.risk past posts before 2014 http://www.garlic.com/~lynn/submisc2.html#security.proportional.to.risk -- virtualization experience starting Jan1968, online at home since Mar1970 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
