In message <[email protected]>, "Robert J. Hansen" <[email protected]> wrote:
>> I have a program. It's written in C. I intend to distribute it, in >> binary form only, to other sites. I do not and will not control how >> any fo the local disks are configured at those other sites. > >The question then becomes, "who are you securing this data against?" If >your goal is to keep data on someone else's computer in a form that they >can't read, you should be advised going in that it's a fool's errand. >Can't be done. See my other post from today. Yes. I know. I understand that my program will be decrypting the data block, and that my program can be disassembled, and thus, the lock effectively picked. And I most assuredly do understand that such disassembly & analysis doesn't even involve, as they say "rocket surgery". Fortunately, I am not attempting to defend the data from nation states, nor even from anyone who is seriously motivated, i.e. to do the disassembly and subsequent analysis. I just want to keep out those with ernest, but not too intensely motivated curiosity. >As an example of how it can be foiled: while your program is running, >tell the computer to hibernate.... Yes, and yada yada yada. I get it. In this case, breaking the security wouldn't even be that complicated. Just disassemble the bloody thing, look for the routine that does the decryption and see what key is being passed to that. Easy. I cannot prevent _any_ of the numerous scenarios along these lines, and I'm not going to be trying to do so. Security is all relative... relative to what you are trying to protect. I just read this story the other day, which I suspect many others on this list probably also saw, in one place or another: http://www.popsci.com/article/technology/security-experts-build-150-safecracker Do we think that everybody we read this story immediately threw out their old combination lock safes? No, of course not. Nor has that become even advisable in all cases. If you have 20 full-sized bars of gold in your combination lock safe, then yea, you might want to start thinking about alternatives. But if attackers only hope to pry from you your bottle of Chivas Regal 25 and your favorite Reggie Jackson baseball card, then they aren't going to bother _manufacturing_ one of those devices described in the above news story, let alone babysitting it for up to four days while it tries every combination until it gets the right one. Alas, I don't have anything of equivalent value to a gold bar to protect. Just some rather modest secrets. >This is not an abstract or theoretical thing. This is real. I know. I understand. My program will be hackable. I understand the threat, I understand that it is real, and I have already accepted it as part of the price for doing things the way I want to do them. Now I just need something that doesn't make the threat any _more_ real, in practice, than it already needs to be, based on what I want to do and how I plan to do it. And I prefer not to invest too much time & energy into this part of the project, precisely because I do know that the program itself will always be hackable, e.g. to tease the key(s) out it. >> There *are* simply solutions to this rather trivial and common problem. > >If you're doing what I suspect you're doing, there really aren't any. >There are a lot of techniques that don't work at all, and of those some >are simple, and a lot of people use them without knowing that they don't >work, instead believing that everything's going swimmingly because they >don't, themselves, know how to break it. Perhaps I understated my knowledge level, thereby leading you to the conclusion that I have inadequate understanding of the risks inherent in my plan. However I do believe that I do understand those risks, and that I've made an informed engineering decision to accept them, but do not wish to make them any worse than they already need to be, based on the plan (i.e. of embedding the decryption, including any and all necessary keys, direcly into a binary which will then be released to any old Tom, Dick and Harry). I understand that this sort of thing would never be recommended by any self-respecting cryptographer in this day and age, because of the obvious and serious insecurities that would thus be created. However as I say, I am _not_ protecting anything as valuable as gold bars here. Just some modest secrets which I would prefer that people not have unless and until they apply some talent and at least a little ernest elbow grease to obtain them. >I'm sorry if you find the libgcrypt manual to be of no use, but if it's >of no use, please consider the possibility that you are not libgcrypt's >intended audience. That is indeed appearing, more and more, as a self-evident truth. But I thank you for stating in plainly. >That's no slight on you, on your coding ability, or your professionalism. Thank you for the courteous way in which you've made this entirely salient point, i.e. that I'm perhaps not the intended audience for the libcrypt manual. >I'm a highly-skilled data forensics nerd, but >when I have to do digital signal processing my eyes glaze over when the >A/V nerds start talking about how the butterfly interleave of the fast >Fourier transform is fundamentally and deeply connected to the roots of >unity. There's no shame in not knowing everything, because really, how >could anyone be expected to? Quite right sir. Believe me, when posting my question, I went out of my way to make no pretense at being any sort of a crypto guru (which I am clearly not). I selected the (technically) lowest-level list I could find, relating to GnuPG and its libraries before posting my question. If there had been a libcrypt-for-newbies or libcrypt--for-dummies mailing list, I would have posted my original question(s) there instead of here. But this list seemed to be the one most likely to be tolerant of non-guru-level questions, so I posted here and hoped for the best. I was thus perhaps understandably dismayed when, after waiting a day, the only response I got seemed to be along the lines of "This is too complicated for you". That was, to say the least, not really satisfying. But now I've gotten several responses with useful pointers to other libraries that might better suit my needs, so I'm a happy camper again. Regards, rfg _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
