Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hp-pcd!hpcvra.cv.hp.com!rnews!hpcvbbs!akcs.scotty
From: akcs.scotty@hpcvbbs.UUCP (SCOTTY THOMPSON)
Newsgroups: comp.sys.handhelds
Subject: Re: Protect for HP48 (attn: Bill Wickes)
Message-ID: <28073ba1:2013.4comp.sys.handhelds;1@hpcvbbs.UUCP>
Date: 13 Apr 91 17:40:09 GMT
References: <27b7409e:2013comp.sys.handhelds@hpcvbbs.UUCP> <2800f701:2013.3comp
Lines: 46

I, too, used Bill's IFERR library to try a password-protection scheme. 
In fact, the first program I tried to write when I unpacked my first rev.
"a" machine was a protection program.  I believe the first call I made to
tech support was "how to disable the ON key?"  All they said was to keep
watching the BBS and someone would post something.  Well, personally, I
think that all of this IFERR^n THEN^n ELSE^n END^n stuff is ridiculous
(how many nests should we make to be sure?  It's really getting insane to
have an IFERR around an IFERR because when the inner IFERR gets aborted,
the second has to take over...).  Anyway, following is a short password
entry program that is very safe if aborted (no abort code, just
keycodes/flags on the stack).  Also, upon successful entry of a password
(any length), it generates a CRC-length list (from BYTES) and this list
can be used to test the password.  Thus, you can keep your password
anywhere in memory and no-one will know what it is because they'll see a
binary number and a real number in a list.  With the right abort code
preventing anyone from putting this list on the stack for testing, it
should provide excellent protection from prying eyes.  Also, I would
recommend using the CRC code and/or bytes (or some crypt algorithm) to
encode any data that is THAT vulnerable...

The following program is the password entry program.  Nothing is
displayed on the display, to allow you to put your own message (like
"Enter password").  Complete the password with ENTER PROPER.  All
characters are allowed except ON and ENTER PROPER.  Passwords can be any
length, because the length is calculated.  I would like to know the CRC
algorithm, though, HP, so that I could calculate the odds of two pw'ds
(not identical) being compared as identical.  I think including the
length in bytes in the list (with the CRC) should raise the odds
considerably.

------------cut-----------------
\<< RCLF 64 STWS MEM DROP DEPTH \-> dp
  \<< DO
        -1 WAIT
      UNTIL
        DUP 51.1 ==
      END
    DROP DEPTH dp - \->LIST
    BYTES 2 \->LIST
    SWAP STOF
  \>>
\>>
-----------cut-------------------

Short and sweet!  Happy hacking!

<< Hmmm, I feel like a intuitive phrase >>