Re: Reverse-Engineering Bytecode: A Possible Commercial Objection To O'Caml

From: Daniel Ortmann (ortmann@vnet.ibm.com)
Date: Fri Jun 09 2000 - 00:36:38 MET DST

  • Next message: Markus Mottl: "OcamlMakefile"

    Note that althought I brought up the idea of such encryption, I don't really
    have much opinion as to whether it is a good idea. I *do* believe it should
    be discussed.

    ... and not mainly philosophically. But technically. Hopefully that email
    got some people thinking. If so, then that small mission of mine has been
    accomplished.

    Also, isn't "information hiding" part of the purpose of .cmi files? What I am
    suggesting might be viewed as an stronger type of .cmi file ... with REAL
    "implementation hiding". :-)

    Sven LUTHER <luther@dpt-info.u-strasbg.fr> writes:

    > This surely is the philosophy of those who want to make more money using all
    > the free software that other people have developped for free.

    I brought it up precisely because I thought "Maybe this is an idea that occurs
    to me merely *because* I work in a commercial engineering environment? If so,
    then it might not occur to people who are more academically oriented."

    Your response shows the virtue of my email: you were motivated to respond.

    (I wanted to post on this topic a couple of months ago ... but since I know
    the high skill level of the people on this list I had to "work myself up to
    it".)

    > Anyway, i personnaly are not at all in favor for a scheme such as what you
    > propose.

    Ivan Galamian, violin instructor and long time head of the Julliard string
    department said, "A particular technique might go out of style, but the
    ability to do it never goes out of style."

    The ability to manage encrypted byte code, even if provided, might not be
    used. But the ability to do so would not go out of style.

    Today, even when companies "work together" and use each other's chips, models,
    and other circuitry, they distribute encrypted SPICE models or blackbox driver
    specifications called "IBIS".

    We're stuck with encryption. Worse, with multiple incompatible encryption. :-(

    > But then i am a Debian GNU/Linux developper and my opinion might be a bit
    > biased on this.

    I know MANY people inside IBM who are actively lobbying for much more use of
    Linux ... as well as general support for the Open Source movement (i.e. more
    than in words). While I personally use FreeBSD at home, I would love to see
    Linux and GNU use increase. At work. In homes. Everywhere.

    The problem is that many upper level people who control the money often
    believe that the Open Source movement is anti-business. (Hint, hint:-)

    > Still, please remmeber a few things :

    > 1) Reverse engineering is legal in many european countries.

    I did not know that.

    Is "making it hard to reverse engineer" illegal? :-)

    > 2) Encryption is illegal in many countries, or at least export restricted, i
    > think france changed this some time ago, but if not, it would not be
    > possible for inria to distribute such a product.

    I believe the US has just lightened up on some of the restrictions.

    ... But the answer would be: Don't distribute the actual encryptiong directly
    with O'Caml, just the hooks. Have the actual files containing the encryption
    available from non-restricted sites just as FreeBSD does. (I'd guess that
    Linux does something similar?:-)

    > 3) Well this would be a big step back in what the has been achieved in
    > freedom of software and sharing of ressources.

    I would interpret the idea as "allowing people do have control over what they
    wish to share and what they wish to keep private."

    > Caml has a too small community today that you can permit to hamper it by
    > being overly protectionist. And despite what you may think, it would be more
    > important fro ocaml to be adopted by the "free" software community (that is
    > all the linux/*bsd/whatever users), than by the "non-free" one (that is the
    > people you have in mind).

    I believe you are correct. However, the options are not mutually exclusive
    for the following reasons:

    a) I am NOT saying "Everything should be encrypted". Absolutely not. I am
       saying "Consider what might need to be done technically to make such a
       thing possible."

    b) "Aiding the Open Source movement" is not the same thing as "restricting
       business possibilies".

    c) If O'Caml is good for Open Source, it is certainly good for business. Any
       territory gained by O'Caml in business is not taken from Open Source.

    Are there specific ways and reasons how and why adding such possibilities
    would hurt the Open Source movement? I am especially interested in technical
    problems.

    > Since the former surely will contain all the programmers in formation who
    > will later become programmers and decider of the second group. Also
    > remember that many big companies are going for the "free" movement, like IBM
    > and SGI for example.

    I've heard words and slogans ... and some larger plans. But the real interest
    is in the popular movement inside IBM. In fact "the deciders" are most often
    Myer-Briggs "ISTJ" types who think "long term" means "next month". :-/

    In fact I've seen people with ideas desparately avoid becoming managers, even
    skipping meetings to establish a reputation as non-manager material. :-)

    > 4) Is there really a need for this, would the complexity of doing so not
    > outweigh the benefit ?

    I don't know. I am admittedly the only one that I know of who has asked the
    question.

    But how hard would it be?
    a) If it's easy, then why not do it?
    b) If it's hard, does the difficulty point out any technical flaws in O'Caml?
    c) If a) or b), then might the answer be "do it in either case"?

    :-)

    > 5) In particluar there is a theory that says that security though peer
    > review permitted by open source developpment model is higher than security
    > trough hiding which you are suggesting. Or else you will find yourself with
    > a microsoftian type of product (buggy, hidden, expensive, ...), which i
    > doubt is something the ocaml community wish to be associated with.

    I believe you are likely correct.

    > 6) If someone is good enough to reverse engineer your ocaml bytecode, i
    > think he is good enough also to reverse engineer your encrypted stuff, or at
    > least to find holes in the security of it.

    I just "reverse engineered" emacs byte code by doing
    <control> x <control> r ~/.emacs.elc ... and easily viewed actual lisp code.

    That's how easy it was. That's the kind of thing I was thinking about
    avoiding.

    > 7) If you think the bytecode security is not enough for you, just use native
    > code, it is faster anyway, and i doubt you will have less hideance in this
    > than writting in C or C++, ...

    Yes, that is a possibility.

    But what if someone wants to develop a special mathematical toolbox and
    provide it via byte code? The byte code is platform independent ... but in
    this case you want it somewhat hidden.

    After all, isn't that the purpose of .cmi files? Hiding information?

    What I am suggesting could be viewed as an stronger type of .cmi file ... with
    REAL "implementation hiding". :-)

    If you don't agree with that, could you tell me why one type of hiding is good
    and the other bad? (The question is rhetorical, of course.)

    > 8) Finally, if all the above don't convince you, Ocaml is now available
    > under a free license, and thus you are free to implement such a scheme, if
    > you want so. This may not be the best fro the ocaml community, but still you
    > can do it.

    Ummmm... This suggestion troubles me more than any of the rest. :-(
    Leaving some things up to users is good, but *not* everything.

    Consider what happened with Scheme. Here is a quote from a news post by
    Olin Shivers:

        Programming in Scheme is an extremely unportable task if you do anything
        serious. Scheme is much less portable than, say, tcl or C. So we are
        unable to build on each other's work, but must instead keep re-inventing
        the wheel.

        If you *union* up the technology and features in all the Scheme
        implementations out there, you have an amazing tool. But each
        implementation is different, and all lack some important features. You
        don't hear people saying, "I wrote my program in SGI's implementation of C
        -- I can't run it on your Linux box because the struct declarations are
        different, and Linux's C implementation doesn't have do-while loops. Also,
        the interface the Unix write() function is different, so I'd have to
        rewrite all the I/O."

        I couldn't solve my problem in Scheme. And I am tolerably well acquainted
        with the language and its implementations. I could solve my problem with
        tcl. The server we were running had a tcl interpreter linked in, and the
        tcl system had hooks to an RDBM interface. Took an evening.

        As long as this situation persists, the Scheme community can snipe about
        what a lousy, poorly-designed language tcl is, but they aren't in a
        position to offer a credible alternative. So it is just empty flaming. So
        why post?

        Go fix the problem.
                        -- Olin Shivers

    I personally *am* a strong believer in "reinventing the wheel" ... because it
    makes me good at reinventing. :-) But then I compare against standard
    prefix stuff, re-work the code, and do it also the "right" way.

    > As a personal note, if it is not confidential, what are the personal
    > interrest that make you ask yourself this kind of questions, are you aware
    > of a particular company which ask this kind of question when faced with
    > ocaml ?

    It's not confidential. I'm the only one I know who has asked the question.
    In fact, I've not yet implemented *any* actual solutions with it here at IBM
    in O'Caml. I've tried to be sensitive to the concerns of my colleagues and
    hold back on some change for awhile.

    (I am the sort of person who always helped everyone else with their homework
    and forgot to do my own.:-)

    The problems I've run into have included things such as:

    a) Public relations about O'Caml, (informing people around me gains me more
       freedom to act in the future.) I've had to hold back and limit myself to
       reading and informing ... I think I've built enough trust to start using it
       soon.

    b) Compiling problems. I've had very poor results with local versions of GNU
       GCC on our AIX/RS6000 systems. Can't link to various libraries, problems
       with shared libraries, problems with compiler crashes, problems with
       crashes of programs compiled with GCC, etc, etc. (It works great on
       FreeBSD.)

    c) Whenever I recompile *anything* ... I recompile *everything*, including
       almost all supporting libraries. I dread it. :-(

    d) Lately I've even had some problems compiling with using our own compiler on
    my system. I think I need to reinstall or upgrade the OS.

    > And i hope this few remarks can contribute to this discution, please don't
    > take them negatively, if i was unexact or maybe offending somewhere.

    I actually have a GENERAL PURPOSE 2-step problem solving process which can be
    used to solve ANY problem. The advantage is that the second step is trivial,
    and the first step applies to ALL problems. The steps are, 1) learn
    everything in the universe, 2) solve problem.

    I'm still working on the first step. :-)

    --
    Daniel Ortmann, IBM Circuit Technology, Rochester, MN 55901-7829
    ortmann@vnet.ibm.com or ortmann@us.ibm.com and 507.253.6795 (external)
    ortmann@rchland.ibm.com and tieline 8.553.6795 (internal)
    ortmann@isl.net and 507.288.7732 (home)
    

    "The answers are so simple, and we all know where to look, but it's easier just to avoid the question." -- Kansas



    This archive was generated by hypermail 2b29 : Fri Jun 09 2000 - 19:35:00 MET DST