Libcrypt examples?

[Ronald F. Guilmette]

I'm sorry that I could not reply right away.  I was called to other
duties.

In message <8738aomjb1.fsf at vigenere.g10code.de>, 
Werner Koch <wk at gnupg.org> wrote:

>On Wed, 15 Oct 2014 23:45, rfg at tristatelogic.com said:
>
>> detailed, 134 page (PDF) manual for the library, and yet prospective
>> users of the library, such as myself, cannot find even a single modest,
>> real-world example of how to use the bloody thing.
>
>IIRC, it has already been quoted from the introduction:
>
>  The reader is assumed to possess basic knowledge about applied
>  cryptography.

I believe that I do indeed already have "basic" knowledge of the subject.

>That is really important and it means that the reader knows what an IV
>is, what an encryption mode is and which one first which purpose,why
>padding is required, and so on.  Well, maybe this is a bit more than
>"basic knowledge" but for us crypto plumbers this is basic.

I understand why padding may be required, I'm not sure what you mean
by "IV", and as regards to the "mode", I think that I specified in my
original post that symmetric key would be just fine for my purposes.
(Did you mean something else by your use of the term "mode" in this
context?  If so, what?)

>> OK.  Swell.  Ignoring, for the moment, the personal condescension
>> implicit in your comments, and accepting your premise that I should
>> be using some ``higher level'' library, the question remains:  Which
>> one?
>
>I would suggest GPGME.

Ah!  Thank you.  Now *that* looks like it may in fact be a useful and
actionable bit of information.  I did not know about that alternate
library until just now.  I confess that missed it, when looking at this
page:

  https://www.gnupg.org/related_software/libraries.html

because it wasn't immediately obvious that this was even a library, as
opposed to a program.  (Even though this is a page decicated to listing
"libraries" I guess I was thrown off by the first entry on that page,
which appears to refer to something which I gather is most likely a
program, and not a library at all.)

>However, there is a lot of extra baggage which
>comes with that, for example you need to install GnuPG proper, because
>GPGME makes use of it.

I'm OK with "extra baggage".

>Thus for your goal, direct use of Libgcrypt might me right.  However,
>before you can use it you need to answer seeveral design questions.  For
>example:
>
> - From where do I take the key?

The key will be embedded in the compiled binary of the program I'm building.

> - Do I need to derive the key from Passphrase.

I hope not.  I want this simple.  There should be no pass phrase... just
a pre-manufactured key.

> - Which cipher mode to use.

As I said, syymetric key will be just fine for me.  I most certainly
*do not* need public key cryptography.

And while we are on that subject please allow me to point out what may
perhaps be a deal-breaker for me when it comes to the GPGME library.
I'm looking at this page:

  https://www.gnupg.org/documentation/manuals/gpgme/Algorithms.html#Algorithms

and I am *not* seeing any mention of any symmetric key stuff.

Was that stuff just not considered sufficiently important to put interfaces
for it into GPGME?  (Correct me if I'm wrong, but there _is_ some syymetric
key stuff within Libcrypt itself, right?)

> - Where do I store extra data like an IV

As per above, I don't know what you are referring to.

> - Do I need padding.

I will assume so until advised otherwise.

> - Do I need authenticated encryption?

Nope.

>To answer this it would be best to first describe the thread model.

Did you mean to say "threat model"?  I'll assume that you did since,
in a subsequent posrt, I see that Peter Lebbing also asked about my
"threat model".

So, I'll do my best to try to respond to that question.

As I said at the outset, my current intention is to have/build a compiled
binary program which will be distributed to many sites and many parties.
(In fact it will most probably be available for free download.)  The
program in question will, when properly installed, provide some useful
functionality within the general "security" space.  (Anybody who googles
me for about 10 minutes will probably uncover my particular area of
interest, but that's not really important now.) The program's actions
and decisions will be driven by a set of external data tables, which
will be stored on disk and which will change over time.  The program
itself will be proprietary, i.e. I will not wish for either customers
or competitors to have ridiculously easy time determinding either what
it does, exactly, or how it does it.  More essentially, I will not want
it to be ridiculously easy for ``attackers'' to figure out what the
program does, exactly, or how it does it.  If they do, then the effective-
ness of the program itself will be rendered... in the words of Ronald
Regan...  "impotent and obsolete".

My assumption from the outset is that *any* seriously determined customer,
competitor, or attacker *will* be able to disassemble the program, recon-
struct its logic, and thus figure out entirely what it is doing and how
it is doing it.  I further assume that this possibility will not by
any means be limited to nation states.  (Note that under this scenario,
it would not even be necessary for the attacker to _completely_ disassemble
and reconstruct the entire logic of the program in order to see what it
is doing and how it is doing it.  If disassembly and analysis only went
deep enough to obatin from the program the embedded decryption key that
it uses to obtain the plain text version of the on-disk data file, then
this would be enough, by itself, to fully compromise the program, because
the data file, in plain text, would pretty much give away what the program
is doing and how it is doing it.)

An alternative attack which would not involve disassembly of the compiled
binary would be to for the attacker to simply decrypt the associated
on-disk data file.  I mentioned just above, the plain text of the data
file would itself pretty completely give away both (a) what the program
is doing and also (b) how it is doing it.  It is this precisely and only
this alternative attack scenario that I am keen to avoid, or at least
render equally as difficiult, or more difficult than the disassembly
approach (which itself is not really that hard).

In short, I do not need iron-clad or world-beating cryptography here.
Dissasembly of the binary will always be possible, and I cannot stop
that.  I just want some encryption applied to the data file which will
make the disassembly route the _easier_ route to breaking into the logic
of the program.  (I also do not want to use something so lame, in the
way of encrption, that I'll embarass myself in front of the potential
users of the program.)

I suspect that this may be the source of what I sense is a bit of a
disconnect between myself and other participants on this maling list,
perhaps including, but not limited to you.  I understand that
cryptographers generally are _not_ in the habit of producing tools
or methods that are ``just good enough'' for applications such a
mine, but rather are constantly striving to produce tools and methods
that are sufficiently iron clad to be entirely impenetrable, even to
nation states.  That is of course laudable, and as events of the past
year have shown, desperately needed by all of us, e.g. to protect our
privacy from extraordinarily well-funded adversaries.  But for this
one application, for the reasons I've described above, I really do
just need soething that is only just good enough.

>However, there are some standard solutions which may fit for you.  There
>are good books which describe how to come up with a good solution.  For
>example...

Books are good.  I like books.  Schneier's are especially good.  But
I'm not looking for a course on cryptography generally.  I'm looking
for _specific_ information about how to use _your_ libraries, very
specifically.  Some modest examples would help.

Unless Schneier has written a book which describes the interfaces and
semantics of either Libcrypt or GPGME, his books won't help me.  But
you still could... with some trivial examples.

>> P.S.  I'm still looking for the "examples at the end of the manual"
>> which were explicitly promised in Section 1.1 ("Getting Started")
>> of the Libcrypt manual.
>
>Thanks for the hint; it is probably missing.

That appears to be the case.

Don't get me wrong.  I am quite completely sure, even from just briefly
skimming the manual, that it is, in the tradition of all GNU manuals,
well written, comprehensive, and exquisitely detailed in its description
of its subject matter.  Unfortunately, I'm sad to say, I just don't have
the time right now to read and comprehend 134 pages of technically dense
material, most of which is surely going to be new to me.  I'd enjoy
doing that, but I have a product to build.

Given my time pressure, I latched on to the following statement, which
appears in Section 1.1 of the manual:

   "Experienced programmers might want to start looking at the examples
   at the end of the manual, and then only read up those parts of the
   interface which are unclear."

As it happens, I do in fact qualify as an "experienced programmer", and
thus I had hoped to be able to do as advised (by the above quote).

>We should fix the manual in some way.

That would almost certainly be helpful, however please don't feel in any
way obliged, either to wait until you can generate and perfectly format
some examples within the PDF, or INFO, or HTML versions of the manual,
or until you have time to develop some really excellent examples of how
to use each and every feature of the library.  Rather, I would be very
happy if you could just post a short example here, on list, and in plain
text, of a simple code snippet that would do just the one small thing
I need to have done.  (You can always go back and fix the manual at a
later time.)

Thank you for your fine library, for the generally well-crafted documen-
tation, and for your attention to my own unque and somewhat unusual use
case.


Regards,
rfg