Libcrypt examples?

[Ronald F. Guilmette]

In message <5440196B.8070808 at sixdemonbag.org>, 
"Robert J. Hansen" <rjh at sixdemonbag.org> 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