I'm sorry that I could not reply right away. I was called to other duties.
In message <8738aomjb1....@vigenere.g10code.de>, Werner Koch <w...@gnupg.org> wrote: >On Wed, 15 Oct 2014 23:45, r...@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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
