Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Unusual Encryption Method
#1
I'm not sure if this method has been employed before, but it occurred to me as an easy way to do encryption in QBasic. Suppose you want to encrypt a text file, and for ease of explanation, let's assume that the text is all lower case alphanumerics. First, break the plaintext up into groups of 5 characters. Now instead of looking at each group of 5 as text, you interpret the group as a 5 digit number with a base or radix of 37. I say 37 because our character set has 37 members: 0123456789_abcdefghijklmnopqrstuvwxyz. (I'm substituting an underscore for a space.)

If you are familiar with hexadecimal numbers, you know that A-F represent the numbers 10-15. If we continue through the character set above, "z" would represent the number 36, 37 would be "10" (the second place from the right is 37th's place), and 100(base 10) would be 2p(base 37).

Now suppose that instead of converting each 5 character group to base 10, we convert it from base 37 to base 38. In order to do so, we need one more character to the right of "z". I used the vertical bar (|) for this purpose in the demo program listed below. The program lets you encode and decode text strings entered at the keyboard. It ignores keypresses not in the above listed character set (except the space bar is OK to use).

Using this method, "qbasic" encrypts to "njk_fc", "aaaaa" encrypts to "_37da", and the phrase "train tracks track trains" becomes "qmtzh9k4z_ibi409vit0o0__2". Decoding returns the original strings.

This is symmetric encryption. The decryption key is simply the character set. I used it in sequence here (012...xyz), but in practice it can be scrambled in any way as long as users at both ends have it.

There are a few refinements in the demo program:

1.) I insert ~ as the leftmost (0 value) character. This eliminates the problem of leading zeros in the plaintext since ~ is not in the plaintext. So with this added character we're actually converting base 38 to base 39.

2.) Infrequently a 5 digit number will encode to a 4 digit result. This would mess up the decoding process, so I pad the left side with ~ if the result is less than 5 digits.

3.) If the same 5 digit string appears more than once in the plaintext, we wouldn't want it to be encoded the same way. To avoid this, I rotate the character set one place to the right after each conversion.

Expanding the demo program into a useable one might include:

-- Increase the size of the character set to include punctuation, etc. I believe the practical limit is 73. Beyond that the numbers get too big for QBasic.

-- Have the program read and write to files instead of getting input from the keyboard (a must).

-- Use a password routine to scramble the character set. A set with 71 characters would have over 8*10^101 permutations.

I really don't know what constitutes strong encryption, and I don't claim that this is anything of the sort. I just think that it's a relatively easy way to encrypt text messages and an interesting diversion for those who like numbers and programming.


DEFLNG T
CLS
DO
PRINT
rx$ = "0123456789_abcdefghijklmnopqrstuvwxyz"
ans$ = "": dnr$ = "": t = 0
PRINT "Choose: encode(e), decode(d), quit(q)"
DO
i$ = LCASE$(INKEY$)
IF i$ = "q" THEN END
LOOP WHILE i$ <> "e" AND i$ <> "d"
IF i$ = "e" THEN
bai = 38: bao = 39
INPUT "Text to encode"; dn$
dn$ = LCASE$(dn$)
FOR p = 1 TO LEN(dn$)
p$ = MID$(dn$, p, 1)
IF p$ = CHR$(32) THEN p$ = CHR$(95)
IF INSTR(rx$, p$) THEN dnr$ = dnr$ + p$
NEXT p
END IF
IF i$ = "d" THEN
bai = 39: bao = 38
INPUT "Text to decode"; dnr$
END IF
FOR p = 1 TO LEN(dnr$) STEP 5
f$ = MID$(dnr$, p, 5)
GOSUB convtodec
GOSUB dectox
rx$ = RIGHT$(rx$, 1) + LEFT$(rx$, 36)
NEXT p
PRINT dnr$ + " = "; ans$
LOOP

REM convtodec converts the input fragment (f$) to base 10 (t)
convtodec:
IF i$ = "d" THEN rxe$ = "~" + rx$ + "|" ELSE rxe$ = "~" + rx$
FOR a = LEN(f$) TO 1 STEP -1
k = LEN(f$) - a
b$ = MID$(f$, a, 1)
c = INSTR(rxe$, b$)
IF c = 0 THEN PRINT : PRINT b$; " is not in character set!": END
t = t + (bai ^ k) * (c - 1)
NEXT
RETURN

REM dectox converts the base 10 number to the output base
dectox:
IF i$ = "e" THEN rxd$ = "~" + rx$ + "|" ELSE rxd$ = "~" + rx$
n = FIX(LOG(t) / LOG(bao))
FOR a = n TO 0 STEP -1
index = INT(t / bao ^ a) + 1
ans$ = ans$ + MID$(rxd$, index, 1)
t = t MOD (bao ^ a)
NEXT a
IF LEN(ans$) < 5 THEN ans$ = STRING$(5 - LEN(ans$), "~") + ans$
RETURN
Reply
#2
An encryption algorithm "from the Jersey side."

It sounds pretty good to me, but then again I'm no expert on encryption either. The code is not that long, and looks pretty straightforward. Let's see what the other guys have to say.
*****
Reply
#3
I find it interesting that you separated 0-9 and A-Z with the space character. Normally, it would be 0-Z followed by the next ASCII character (in this case, the '[' character).
974277320612072617420666C61696C21 (Hexadecimal for those who don't know)
Reply
#4
Interessting idea, too bad it can't handle the full ASCII table.

In addition, it can't handle linebreaks, so you get the exact same structure:
Hi there
This is a message

Would encrypt to two lines, of the exact same lenght..


What you could do is add a "special" char, like \, which would translate to the other ascii codes. As such:
. -> \046
" -> \034

Etc, sure, the crypto would become a bit larger than the original message, but unknown characters would be handled..

If the original message is:
Blarga\0392What

Then you simply encrypt it to:
[blarga]\[ascii code for \, always 3 digits][0392What]
Reply
#5
I used something similar on my Ti-83.
Reply
#6
Any encryption routine should be able to un-encrypt a file to exactly what it started with. With your funky padding that might not be the case...
Peace cannot be obtained without war. Why? If there is already peace, it is unnecessary for war. If there is no peace, there is already war."

Visit www.neobasic.net to see rubbish in all its finest.
Reply
#7
Quote:I find it interesting that you separated 0-9 and A-Z with the space character. Normally, it would be 0-Z followed by the next ASCII character (in this case, the '[' character).

Actually, you can scramble the character set any way that you want. It doesn' t matter as long as all users have it.
Reply
#8
Quote:Interessting idea, too bad it can't handle the full ASCII table.

In addition, it can't handle linebreaks, so you get the exact same structure:
Hi there
This is a message

Would encrypt to two lines, of the exact same lenght..


What you could do is add a "special" char, like \, which would translate to the other ascii codes. As such:
. -> \046
" -> \034

Etc, sure, the crypto would become a bit larger than the original message, but unknown characters would be handled..

If the original message is:
Blarga\0392What

Then you simply encrypt it to:
[blarga]\[ascii code for \, always 3 digits][0392What]


It can handle 71 characters, enough for all the keys on my keyboard, providing you convert the text to upper or lower case before encrypting.

It can handle linebreaks and tab stops. You simply have to add chr$(10), chr$(13),and chr$(9) to the character set.
This way the crypto will be no larger than the original text.
Reply
#9
Quote:Any encryption routine should be able to un-encrypt a file to exactly what it started with. With your funky padding that might not be the case...

The padding is only in the encrypted text. It is removed in the decryption process.
Reply
#10
Quote:This way the crypto will be no larger than the original text.
Well, if you think about it, wouldn't that actually be a good thing? Looking at MIME (base 64) encoding, it's useful to have something longer than the original text. I think I'll create my own encryption technique now. . .
974277320612072617420666C61696C21 (Hexadecimal for those who don't know)
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)