Posting encryption UserRPL illegal? - Hewlett Packard

This is a discussion on Posting encryption UserRPL illegal? - Hewlett Packard ; I was thinking of posting the code for a surprisingly rapid (it accelerates as it operates) and fairly strong encryption program that doesn't require a lot of imagination to make quite a bit stronger. Does anyone know the current law ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Posting encryption UserRPL illegal?

  1. Posting encryption UserRPL illegal?

    I was thinking of posting the code for a surprisingly rapid (it
    accelerates as it operates) and fairly strong encryption program that
    doesn't require a lot of imagination to make quite a bit stronger.

    Does anyone know the current law on this issue? I'd rather not have
    feds knocking at my door over a program for a little calculator.

  2. Re: Posting encryption UserRPL illegal?

    On Sat, 02 Aug 2008 17:54:29 -0500, mike wrote:

    > I was thinking of posting the code for a surprisingly rapid (it
    > accelerates as it operates) and fairly strong encryption program that
    > doesn't require a lot of imagination to make quite a bit stronger.


    > Does anyone know the current law on this issue? I'd rather not have
    > feds knocking at my door over a program for a little calculator.


    Is your method "stronger" than "AES" (U.S. Goverment approved
    for classified information), which is not only public,
    but also included in many products, including WinZip,
    or stronger than PGP/GPG, etc.,
    which are now likewise available to anyone,
    and apparently even exportable?

    Or these?
    http://www.hpcalc.org/search.php?query=encrypt

    If you want reliable legal advice, best to consult a lawyer
    (and then get a second, third, fourth, etc. opinion,
    in case they don't agree) -- meanwhile, have a search:

    http://www.google.com/search?as_q=st...law+legal+ITAR

    Here's what Stanford University thinks:
    http://www.stanford.edu/dept/DoR/exp...cryption1.html

    Of course, "your mileage" (and sentence) may vary

    BTW, if you live or reside outside the USA,
    check the laws of your own country,
    which may be quite different.

    -[ ]-

  3. Re: Posting encryption UserRPL illegal?

    On Aug 2, 4:31*pm, "John H Meyers" wrote:
    -snip-

    Thanks, John.

    As I understand, AES got a special exception made for it. I highly
    doubt that my little program is as strong as stuff written by real
    programmers and cryptographers (as I am neither). But other stuff has
    probably gone through the right legal channels, whereas mine has not.
    I am in the US.

    I'd like to give you special thanks, John, for your TICKS trick for
    the initialization vector. I use it in all of my encryption programs.

    I guess I can describe the core part that makes it run quickly without
    exposing myself to legal worries, as long as I stick to vague terms
    (for the HP48G/GX):

    I have two pseudorandom strings that are generated concurrently with
    their own randomized seeds that keeps getting updated in its own
    variable (neither string is ever output, though). One string grows
    leftward, the other grows rightward. As they slither over each other,
    they are XOR over each other to produce ever-larger chunks of random
    characters that accumulate in a variable "q". When "q" is large
    enough, it is XOR'ed with the plain text, and the initialization
    vector is tacked on the front to prevent reuse-of-key attacks.

    Another interesting thing is the CHR function. It cycles though
    characters for numbers up to almost 1048576, essentially acting as a
    MOD 256 function inherently. So instead of multipling your random
    numbers by 256 before you use CHR, use a separately pseudo-randomly
    chosen large multiplier. This will help to additionally protect your
    PRNG's in a linear congruential manner.

    I like to use the BYTES checksum function (and NUM) as I strip away
    characters to quickly and repeatedly extract all the entropy that's
    available in the key phrase. Making use of the plaintext length in
    this process also helps a little like a mini initialization vector.
    And the HP can help you produce some wicked keys if you put your mind
    to it with all it's functions. When you write your code, be sure to
    keep your key well insulated from the actual encryption process.

    The basic version in UserRPL has the following speeds (characters per
    second) for various character length strings:

    45 cps/64 chars
    69/128
    102/256
    153/512
    221/1024
    288/2048
    390/4096
    504/8192

    The overkill version (~186 bit) runs about a third slower which still
    isn't bad.

    One accessory component I can fully describe. It converts strings to
    a list of character numbers and vice versa. It's good for exporting
    results in a more user-friendly manner and for doing various analysis
    (like seeing a plot of your output): I'll use ## for program
    delimiters:

    ##
    DUP SIZE -> k
    ##
    DUP TYPE
    IF 2 == THEN
    1 k START DUP NUM SWAP TAIL NEXT
    DROP k
    -> LIST
    ELSE OBJ->
    SWAP CHR SWAP DUP
    IF 1 == THEN DROP
    ELSE 1 SWAP 1 -
    START SWAP CHR SWAP + NEXT
    END
    END

    ##
    ##

    I haven't given it a lot of attention, so it should be able to be
    better optimized.

  4. Re: Posting encryption UserRPL illegal?

    On Aug 2, 6:54*pm, mike wrote:
    > I was thinking of posting the code for a surprisingly rapid (it
    > accelerates as it operates) and fairly strong encryption program that
    > doesn't require a lot of imagination to make quite a bit stronger.
    >
    > Does anyone know the current law on this issue? *I'd rather not have
    > feds knocking at my door over a program for a little calculator. *


    IANAL, however I have looked into this at length before.
    If you are publishing only source code and the code is "Publicly
    Available" then the only legal requirement is to send a notification
    to the right place. This can apparently be be done via e-mail. See
    http://www.bis.doc.gov/encryption/pu...odenofify.html

    However, I can also tell you that right now that any encryption method
    you have created is almost certainly very weak. Consider than even
    Bruce Schneider, one of the foremost experts on cryptography has
    created encryption algorithms with some serious flaws without
    realizing it. (See the Solitaire encryption algorithm.)

    In reality for a small and almost certainly far weaker than yu
    actually think encryption alorithm whose source is posted publicly,
    the federal government is really not going to care. AFAICT what is
    important to the government is that they can get access to the source
    code of any encryption program potentially used by attackers, to give
    them a fighting chance of breaking it. If the source is published in
    such a fashion that Google will index it, then they would have no
    problem there.

    But if you want to be safe, you can send a message to the right
    people. I almost doubt it will ever even be read.

  5. Re: Posting encryption UserRPL illegal?

    Poking into my calculator for some UserRPL utilities:

    @ List of character numbers -> string [all HP48/49/50]
    \<< LIST\-> \-> n \<< "" n { 1. n START
    SWAP CHR SWAP #5193h SYSEVAL NEXT } IFT \>> \>> 'CHRL' STO

    Although \<< \<< CHR \>> DOLIST \GSLIST \>>
    is minimal programming (but takes lots longer).

    It's considered a good idea to make a memory backup
    before trying anything containing SYSEVAL
    (I do not sell insurance against "Memory Lost"

    Note the important "h" in #5193h

    I thought I had an inverse of this function somewhere,
    but don't see it -- maybe it can be based on this:

    @ "string" -> { list of single characters }
    \<< DUP 1. OVER SIZE FOR n DROP n DUP2 DUP SUB
    ROT ROT NEXT SWAP DROP \->LIST \>> 'XPLOD'

    To get numbers instead of characters, insert NUM after SUB;
    replace ROT ROT with UNROT (and of less significance,
    SWAP DROP with NIP) on 49/50:

    @ "string" -> { list of numbers }
    \<< DUP 1. OVER SIZE FOR n DROP n DUP2 DUP SUB NUM
    UNROT NEXT NIP \->LIST \>> 'CHRN' STO

    One should also completely "wipe" calc "temporary memory"
    after encryption, or else it may be possible
    to recover the original text, much as it's desirable
    for computer encryption programs
    not to leave everything they've been working on
    in the "swap" (memory paging) or other "memory-mapping" file.

    Newsgroup sci.crypt is a good place for evaluating ideas
    for new cryptosystems (except secret ones,
    but they always criticize "security by obscurity,"
    or the very idea of trying to keep any system "secret").

    Best wishes.

    [r->] [OFF]

  6. Re: Posting encryption UserRPL illegal?

    On Aug 2, 7:49*pm, username localhost
    wrote:
    > On Aug 2, 6:54*pm, mike wrote:
    >
    > > I was thinking of posting the code for a surprisingly rapid (it
    > > accelerates as it operates) and fairly strong encryption program that
    > > doesn't require a lot of imagination to make quite a bit stronger.

    >
    > > Does anyone know the current law on this issue? *I'd rather not have
    > > feds knocking at my door over a program for a little calculator. *

    >
    > IANAL, however I have looked into this at length before.
    > If you are publishing only source code and the code is "Publicly
    > Available" then the only legal requirement is to send a notification
    > to the right place. This can apparently be be done via e-mail. Seehttp://www.bis.doc.gov/encryption/pubavailencsourcecodenofify.html
    >
    > However, I can also tell you that right now that any encryption method
    > you have created is almost certainly very weak. Consider than even
    > Bruce Schneider, one of the foremost experts on cryptography has
    > created encryption algorithms with some serious flaws without
    > realizing it. (See the Solitaire encryption algorithm.)
    >
    > In reality for a small and almost certainly far weaker than yu
    > actually think encryption alorithm whose source is posted publicly,
    > the federal government is really not going to care. AFAICT what is
    > important to the government is that they can get access to the source
    > code of any encryption program potentially used by attackers, to give
    > them a fighting chance of breaking it. If the source is published in
    > such a fashion that Google will index it, then they would have no
    > problem there.
    >
    > But if you want to be safe, you can send a message to the right
    > people. I almost doubt it will ever even be read.


    A few hours after I wrote my post, I realized the weakness in what I
    was doing and I'm kicking myself now. Each chunk has clues that can
    help figure out spots of other chunks.
    I guess I'll have to go back to my slower programs.

    So to all: Nevermind. Next time I'll take more time to think over
    what I have.

  7. Re: Posting encryption UserRPL illegal?

    On Sat, 02 Aug 2008 22:39:40 -0500, mike wrote:

    > I realized the weakness in what I was doing...
    > I guess I'll have to go back to my slower programs.


    When a cryptosystem works by repeating "rounds"
    of the exact same procedure, the authors seem to agonize
    over just how many rounds to perform;
    too many will seem a wasted "slowness," and their system
    will not seem to be advantageous in comparison to others,
    while too few will lead to an opposite disaster,
    as one after another "attack on somewhat reduced-round
    version of xxxx" is announced by others in the profession

    For example:
    http://www.schneier.com/paper-serpent-aes.html
    http://www.springerlink.com/content/5672351036513371/

    Beating the world's most experienced pros at
    "resistance to attack per CPU cycle spent"
    is a tough challenge, which is probably why
    "well-known" standard systems are preferred.

    All the same, some of those should be easier and faster
    to perform on this sort of calculator than others.

    Since complex bit shuffling seems a bit harder
    than simple arithmetic, I wonder why I didn't see
    an implementation of the IDEA cipher (originally
    the single "symmetric cipher" used in some basic PGP versions)
    for these calculators, which is based mostly
    on 16-bit-word arithmetic and exclusive-OR,
    plus a little whole-word rotation.

    But once again, the sharks are racing to devour IDEA:
    "As of 2007, the best attack which applies to all keys
    can break IDEA reduced to 6 rounds (the full IDEA cipher uses 8.5 rounds)"
    http://en.wikipedia.org/wiki/Interna...tion_Algorithm

    RC4 (a "stream cipher" frequently used in SSL/TLS throughout the internet)
    is also mighty fast, involving a lot of swapping bytes in memory:
    http://en.wikipedia.org/wiki/RC4

    "CipherSaber," based on RC4, was also recommended
    as a way to defeat laws banning "export" of encryption programs,
    because one can easily memorize how it works,
    and write one's own program from scratch at any time:
    http://en.wikipedia.org/wiki/CipherSaber
    http://ciphersaber.gurus.org/

    Another simple one (which I recall implementing in Sharp Wizard Basic
    http://en.wikipedia.org/wiki/Tiny_Encryption_Algorithm

    So, if you're giving up on the system you had just invented yourself,
    there is a large field of pre-tested (and possibly fast)
    alternatives to try implementing in its place,
    if your "slower programs" haven't already done this anyway

    Best wishes.

    -[ ]-

+ Reply to Thread