Thread View: comp.sources.hp48
1 messages
1 total messages
Started by Simone Rapisarda
Wed, 18 Nov 1992 03:44
v07i030: coder.sr - CODER v1.4, CODER1 v1.0, CODER2 v1.0: Three Strings Encoders/Decoders, Part01/01
Author: Simone Rapisarda
Date: Wed, 18 Nov 1992 03:44
Date: Wed, 18 Nov 1992 03:44
340 lines
11713 bytes
11713 bytes
Checksum: 1583247124 (verify with brik -cv)
Submitted-by: Simone Rapisarda <Simone.Rapisarda@p10.f800.n33.z2.fidonet.org>
Posting-number: Volume 7, Issue 30
Archive-name: coder.sr/part01
BEGIN_RDME coder.rdm
Jim Weisbin reported a bug in CODER which cause it to crash when the string
to encode/decode is empty.
I removed the bug and, while I was working on it, I optimized the code too.
I also removed the possibility to use other objects instead of strings: in
this way the result is safer than before.
Both the strings may now be tagged, the tags are removed.
While I was at it I devoleped other two safer but slower versions of CODER
that I called CODER1 and CODER2. So the following doc describes now a set of
three different (but similar) strings encoder/decoder.
Please excuse my bad english.
ciao
RAP
END_RDME
BEGIN_DOC coder.doc
Do you keep any top-secret data in your HP48?
If yes, the following set of sys-RPL programs will be very useful to you.
=============================================================================
C O D E R v1.4
-----------------
C O D E R 1 v1.0
-----------------
C O D E R 2 v1.0
-----------------
STRING CODERS & DECODERS
by
Simone A. Rapisarda
These utilities are dedicated
to Jim Weisbin, with gratitude
for his excellent ROLDX program.
=============================================================================
+-------------+
| CODER v1.4 |
+-------------+
CODER requires two arguments: a string to encode/decode on level two and a
key string on level one.
The two strings can be of any length, the longer is the key the safer the
encoded string is. If the two strings have the same lenght, the decoding
of an encoded string without the right key is impossible. If the key string
is longer than the string to encode/decode it will be truncated.
The algorithm used is very simple. The program is only 57.5 bytes long. The
coding of a 1000 character string with a 5 character key takes about 0.1
seconds.
USAGE 1
|3: | |3: |
|2: "String to Encode"| |2: |
|1: "Key"| ----> |1: "Encoded String"|
|CODER ### ### ### ### ### | |CODER ### ### ### ### ### |
+=====---------------------+ +--------------------------+
USAGE 2
|3: | |3: |
|2: "String to Decode"| |2: |
|1: "Key"| ----> |1: "Decoded String"|
|CODER ### ### ### ### ### | |CODER ### ### ### ### ### |
+=====---------------------+ +--------------------------+
EXAMPLE 1
|3: | |3: |
|2: "ABCDEFGHIJKLMNOPQ"| |2: |
|1: "988"| ----> |1 "xz{}}~~pqssttvwii"|
|CODER ### ### ### ### ### | |CODER ### ### ### ### ### |
+=====---------------------+ +--------------------------+
EXAMPLE 2
|3: | |3: |
|2: "xz{}}~~pqssttvwii"| |2: |
|1: "988"| ----> |1: "ABCDEFGHIJKLMNOPQ"|
|CODER ### ### ### ### ### | |CODER ### ### ### ### ### |
+=====---------------------+ +--------------------------+
=============================================================================
+--------------+
| CODER1 v1.0 |
+--------------+
CODER1 requires the same arguments as CODER and behaves in the same way.
The only difference is the method used to encode the string that is much
more safer:
- A short key gives excellent results.
- The result is not statistically weak as for CODER.
- The alghoritm used is slower: a 1000 character string takes 7.5 seconds
and a 100 character string takes 0.3 seconds.
=============================================================================
+--------------+
| CODER2 v1.0 |
+--------------+
CODER2 requires a String on level two and a Real on level one. The String is
the text to be encoded/decoded and the Real is the key. So the only
difference with thew other two programs is that the key is a Real number and
not a String. This is the safest of the three encoder but it's also the
slower: 21.5 seconds for a 1000 character string and 1.4 seconds for a 100
caracter string.
The Real can be in the range [ MINR, MAXR ] the sign is not used. If the Real
is 0 then the String is not processed.
=============================================================================
Happy Encoding!
RAP
END_DOC
BEGIN_SRC coder.src
I'm a studend attending the second year of Computer Science and I'm not a
professional cryptographer. I've never read articles or books about
cryptology. The behaviour of these three programs came from my personal
considerations and experimentations on the subject and expecially on the XOR
instruction that is the only reversable logic operator. I would really
appreciate any comment or suggestion and particularly a description of the
eventual weaknesses of the algorithms I developed. I know only that for
persons with no experience in cryptology, like me, it should be impossible,
or, at least, very difficult, to discover the original text without the right
key, expecially for CODER2 and CODER1.
Here is the sys-RPL listing of the programs with some stack diagram and
description. As it's all vanilla sys-RPL I think you should have no problem
to understand what these programs do.
+-------------+
| CODER v1.4 |
+-------------+
Jim Weisbin writes:
"CODER works like this: If the string to decode is longer than the password,
the password is repeatedly concatenated to itself until its length equals or
exceeds the string. The two strings are then XOR'd, in system-RPL. Simple,
but effective!"
::
CK2NOLASTWD
CK&DISPATCH0
FIFTYONE -> ( $Text $Key )
::
DUPNULL$? -> ( $Text $Key Flag )
caseDROP -> ( $Text )
OVERLEN$ -> ( $Text $Key #TextLen )
SWAP -> ( $Text #TextLen $Key )
BEGIN
2DUP -> ( $Text #TextLen $Key #TextLen $Key )
LEN$ -> ( $Text #TextLen $Key #TextLen #KeyLen )
#> -> ( $Text #TextLen $Key Flag )
OVERSWAP -> ( $Text #TextLen $Key $Key Flag )
WHILE -> ( $Text #TextLen $Key $Key )
&$ -> ( $Text #TextLen $Key )
REPEAT -> ( $Text #TextLen $Key $Key )
DROPONE -> ( $Text #TextLen $Key #1 )
ROT -> ( $Text $Key #1 #TextLen )
SUB$ -> ( $Text $Key )
XOR$ -> ( $NewText )
;
;
+--------------+
| CODER1 v1.0 |
+--------------+
The program takes the CRC of the Key, turns it into a two character String
and append it to the Key. This is done repeatedly until the Key is longer
then the text. The Key is finally truncated so to cut off the original key
from the new key and then the two strings are XOR'd.
::
CK2NOLASTWD
CK&DISPATCH0
FIFTYONE -> ( $Text $Key )
::
OVERLEN$ -> ( $Text $Key #TextLen )
DUP#0= -> ( $Text $Key #TextLen Flag )
case2DROP -> ( $Text )
OVERLEN$ -> ( $Text $Key #TextLen #KeyLen )
#0= -> ( $Text $Key #TextLen Flag )
case2DROP -> ( $Text )
#1+ -> ( $Text $Key #TextLen+1 )
#2/ -> ( $Text $Key #(TextLen+1)/2 )
ZERO_DO -> ( $Text $Key )
DUP -> ( $Text $Key $Key )
OCRC -> ( $Text $Key #KeyBytes HXSKeyCRC )
SWAPDROP -> ( $Text $Key HXSKeyCRC )
SWAP&$ -> ( $Text $Key )
LOOP
OVERLEN$ -> ( $Text $Key #TextLen )
ONESWAP -> ( $Text $Key #1 #TextLen )
SUB$ -> ( $Text $Key )
XOR$ -> ( $NewText )
;
;
+--------------+
| CODER2 v1.0 |
+--------------+
The Real number (the Key) is stored as the seed of the pseudo-random number
generator that is used to create a String (the real Key) of pseudo-random
characters with the same lenght of the text. The two Strings are finally
XOR'd. The slow part of the code is the pseudo-random character generation
that could be easely speeded-up about twenty times by a simple ML routine.
Sorry but at the moment I'm not able to do this.
::
CK2NOLASTWD
CK&DISPATCH0
FORTYNINE -> ( $Text %Key )
::
DUP%0= -> ( $Text %Key Flag )
caseDROP -> ( $Text )
DORANDOMIZE -> ( $Text )
NULL$ -> ( $Text $Key )
OVERLEN$ -> ( $Text $Key #TextLen )
DUP#0= -> ( $Text $Key #TextLen Flag )
case2DROP -> ( $Text )
ZERO_DO -> ( $Text $Key )
%RAN -> ( $Text $Key %Random )
% 256 -> ( $Text $Key %Random %256 )
%* -> ( $Text $Key %Random*256 )
%IP># -> ( $Text $Key #Random )
#>CHR -> ( $Text $Key CHRRandom )
>T$ -> ( $Text $Key )
LOOP
XOR$ -> ( $Text )
%0 -> ( $Text %0 )
%RANDOMIZE -> ( $Text )
;
;
END_SRC
BEGIN_ASC coder.asc
%%HP:;
"D9D20D8A81D9F8185B46D9D2090236B491622650322302A170CA1306365038D3
013D26EE170391505E170649265923033750B9881B2130B21301CFC"
END_ASC
BEGIN_ASC coder1.asc
%%HP:;
"D9D20D8A81D9F8185B46D9D20226506622607916226506AC3007916FED30E8E3
03C3708813044950B9F06FE226433702265076E2633750B9881B2130B2130D67
1"
END_ASC
BEGIN_ASC coder2.asc
%%HP:;
"D9D20D8A81D9F8144B46D9D20AAB36B4916B70B2FD5502265066226079163C37
02CFA2339202000000000006520CB9A211CE257A50EE25043370B98814B2A244
0B2B2130B21304E99"
END_ASC
BYTES: #CFC1h 57.5
BEGIN_UU coder.uue
begin 644 coder.bin
M2%!(4#0X+46=+="H&)V/@;5DG2V0(&-+&29B!2,R(!H'K#%@8P6#/1#38NYQ;
5,!D%Y7%@E&*5,C!S!9N(L1(#*S$`N
``
end
END_UU
BYTES: 176Dh 62.5
BEGIN_UU coder1.uue
begin 644 coder1.bin
M2%!(4#0X+46=+="H&)V/@;5DG2T@8@5F(@:782)68,H#<!GVW@../C`\!X@Q"
:0)0%FP_V+F(T<R!B!6<N-G,%FXBQ$@,K,0"76
``
end
END_UU
BYTES: 99E4h 70.5
BEGIN_UU coder2.uue
begin 644 coder2.bin
M2%!(4#0X+46=+="H&)V/0;1DG2V@NF-+&;8'*]]5(&(%9B(&EV'#<R#\*C,I9
B(```````8"7`FRH1[%*G!>Y20#,'FXA!*RI$L+(2`RLQ`"(&7
``
end
END_UU
--
WolfNet BBS Pisa (Italy) Tel. +39-50-589050 300-14.4K Baud Matrix 2:332/602.0
Simone Rapisarda - via FidoNet node 2:33/800
UUCP: ...!gear!wolf!800.10!Simone.Rapisarda
ARPA: Simone.Rapisarda@p10.f800.n33.z2.fidonet.org
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads