Answering a number of comments in order, in one message. First: I don't think being able to encrypt load libraries is worth it. Encrypted executables, in general, are not going to increase security.
Jousma, David: > Encrypt everything with the same HLQ, with the same key.... > that's a big exposure if the key gets accidentally deleted. > Not sure what the rule of thumb is either, as one key per > dataset turns into a key management nightmare. We had a number of long discussions about this topic and we ended up deciding that there isn't a one-size-fits-all answer, so my guidance would be to do what makes sense in your environment. Whenever I speak on this, I always say that one key for all data sets is too few (as is zero), but so is one key per data set (unless you have a really unusual environment. In general, one key for data sets containing "related data" (however you defined that in your environment) is usually a good guideline. > Additionally, I think IBM dropped the ball a bit in that > nothing stops a permitted user to copy that data to an > un-encrypted dataset. Another topic we discussed. Here's the rub: How would you implement that? What would prevent one application from opening a data set and reading, then closing it and opening a new data set to write out. How would IBM detect that? I get that we could have prevented it for IDCAMS REPRO or similar programs but it would impossible to do it reliably for all possible programs. > The technology that I see as beneficial is one that I think > is in the works with ibm in that data will never be decrypted > including during execution. I forget the term used for that. Homomorphic encryption. Phil Smith III: > If the rational is "Encryption is good because encryption", > that's dangerous, because you're not really protecting very > much. Right. I've been in crypto for a pretty long time and this is the kind of message I keep trying to share. While I want everyone to use cryptography, I want them to use for the right reasons, and not just for everything in the world. I had an issue with the "Everything is encrypted" mantra we had for one of our sales pitches for a previous z model. I get the reason behind it but it set the wrong picture in executives' heads. Rick Troth: > Many people use encryption like it was fairy dust: just > sprinkle it liberally and everything is safer. I love your description. Cryptography, when used properly and consistently, does make things safer, but as you said, the emphasis is on both properly AND consistently. > FPE is brilliant. But like everything else, it's not a be-all > and end-all. Agreed. FPE solves a specific problem and does a great job of it, just like data set encryption. Radoslaw Skorupka: > STGADMIN profiles mitigate the problem, but there is also DASD > access from another LPAR and another security rules. This, to me, is the main reason behind data set encryption. The folks who have authority to the key (and the data set) have access to the data. Those who only have access to the key or to the raw encrypted data have nothing. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
