ticalc.org
Basics Archives Community Services Programming
Hardware Help About Search Your Account
   Home :: Community :: Articles :: Calc Crypto and the GPC
Calc Crypto and the GPC

Posted on 3 September 1998

The following text was written by S.T.L.:

Well, it's late at night (yet again) and I'm in the mood for a good rant. Well, this article explores one particular idea, but it's also about a general issue. And somehow, I get to another particular idea after the middle. Ah well. I initally had a long 2-line name, but I suppose "Calc Crypto" is acceptable for "Calculator Encryption".

Quite a while ago, I started to become fascinated with Number Theory (primes and such) and I had a TI-85. Obviously in class, when I had all my work done, I fiddled around with it. I made primality proving programs and all sorts of stuff. But the TI-85 was pretty limited because much of Number Theory involves really huge numbers.

Anyways, that meant that if I *wanted* to do anything remotely nifty, I had to whittle it down into a smaller version so my TI-85 could run the thing. Thus, after reading one of my books, I had an idea. It basically goes back to something that a lot of my classmates do, but I hardly ever: passing notes.

Now, I'm not one to advocate passing notes. But, I know enough to know some features of them:

  • A passed note has to be done in relative secrecy. After all, the teacher certainly can't know what's in the note, eh?
  • A passed note has to be done quickly. This is more of a side-effect of writing them on paper, because if it is passed slowly, then anyone can open it up and read it. You *could* give it to Al, "Hey Al, give this to Bob in your next class, cause I don't have him in any of my classes" but then you have to trust Al.
  • A passed note doesn't contain that much information, but it can contain a fair amount, up to a written pages' worth.

This got me thinking. What if industrial-strength encryption was provided on TI calculators? Now, I'm not talking about cheesy, "I dreamed this up last night" encryption, because every programmer seems to fancy himself a cryptographer. I'm talking about an encryption algorithm that is used in commercial software, and has no easy way to break it. (Yes, it's related to Number Theory.) This could solve problems of classroom communication. (And yes, it could be used elsewhere.) But first, an interlude.

Words used here:

  • Encryption: Scrambling a message so no one can read it, without a Secret Key.
  • Decryption: Descrambling said message with the Secret Key.
  • Public Key Encryption: Most encryption involves two people sharing one secret key. The stuff I'm thinking of allows one person to give everyone their Public Key, which allows messages to be SENT to them, but only their Secret Key would let them read it.
  • Compression: Making a message take up less space.

And we're back.... Now, what would public-key encryption do for note passing? First of all:

  • Forget secrecy. You can scrawl the note on the blackboard, and the teacher won't be able to read it, without intercepting your TI. (Solution: decrypt the message in another class, or get a locking program.)
  • Forget timeliness. You can (w/o scrawling the note on the blackboard) write it down on a sheet of paper, and get your classmates to give it to someone - but you could let them do it next class. Then you don't have to trust them not to read it.

Of course, all these things would be hard unless the program could compress messages. With the ideas I currently have, public keys would be a string of 64 characters, and messages 64 or 128. This is because I know a way for extremely simple Special Purpose Compression, it would really only work for the Calculator Encryption project.

And, importantly, all someone would have to do is give out their Public Key to everyone who has the encryption program. Their Secret Key remains on their calculator, their Public Key goes everywhere. (Public encrypts messages, Secret decrypts messages.)

Well, I've done this for the TI-85 already. Problem was, it used really, really cheesy 8-bit encryption. I can crack that in my head. But with the TI-92, I could program 384-bit encryption. That's the low end of commercial PC software, and the best part is: while it's not immune to the government, or even to a large corporation, it will defeat most anyone a high schooler fears. (Though a large, well-funded university could be amused for a month trying to break it.) I've already got plans as to how to actually implement this thing, too.

My question to everyone, is this concept of Calculator Encryption USEFUL or WORTHLESS? I've only thought of one application for this, but it probably has more. And there are more questions along with this: exactly what SORT of programs would be useful on a TI calculator? For example:

  • I got this idea for Calculator Encryption off of the PC program PGP.
  • The TI-92 Text Editor is basically a PC's NOTEPAD.EXE.
  • Spreadsheets?
  • Games? (Well, I know the answer to this one, but I had to mention it, else everyone would tell me I forgot it.)
  • General Purpose Compressors? (Very, VERY hard to implement, I would guess, but possible.)
  • Other programs?

Actually, the idea of the General Purpose Compressor is VERY interesting. Probably more interesting than Calculator Encryption. *ahem* I think I want to talk about that for a little while. Well, I've gone from a particular idea, to a general idea, back to a particular idea that will turn out to be pretty general. Hehehe. Anyways...

If one had (let's use an abbreviation) a GPC, what TI calculators could it run on? Of course, the TI-92+, the TI-92, and the TI-89. (After all, if it won't run on them, where WOULD a GPC run?) Most likely I could see a TI-86 or TI-85 assembly program running it. Putting a GPC on a TI-83 or TI-82 is doubtful, but maybe a programmer would find a way. Ironically, the more lower-end the calculator, the nifiter a GPC would be. A General Purpose Compressor would crunch programs/data into a smaller space, thus (in effect) giving you more memory, at the cost of not being able to use the compressed program until uncompression. Sort of like the TI-92+ data archive.

Now, I envision a BRIGHT future for a GPC. Imagine being able to store twice the amount of data your calculator should hold (it would probably be closer to 1.5x, but let's stick with 2x). For a TI-85, that's about 40K (or is it 50? I don't remember). For a TI-92, that would be 120K. For a TI-92+, it could store an absolutely amazing 1MB of data! (Though still, no single uncompressed program/data could be more than 180K. Ah, I'll live with it.)

In fact, games (arrrgh! Ah well, I suppose I have to explore what a GPC means to them too) could have a large compressed bundle of levels included with them. When one level is needed, it could be uncompressed, used, then recompressed to make room for the next level. Thus you could create truly massive games with 2x the amount of levels you'd have without a GPC.

And I bet there's all SORTS of nifty applications for a General Purpose Compressor. Though it's 3 in the morning, and I can barely think coherent thoughts. *ahem* I, for one, would love to craft a GPC, though I don't have the assembly skills to do so. Probably it'd be a project close to making a shell.

Right now, the Special Purpose Compressor I have in mind doesn't really compress at all. All it does is transform integers into strings. What it does it convert an integer into base 2. Then it converts the base 2 to base 64. This of course saves space, and makes a 384-bit integer into a 64-character string. This is because the binary expression "110010011011" can be represented as the hexadecimal (base 16) expression "C9B". I think. I'm rusty on my Bin-Hex translating skills. But a General Purpose Compressor could work on real numbers, strings themselves, lists, matrices, and programs.

What's odd is that a list on the TI-92 seems to take up less space than the identical list on the TI-85. Hmmmm. I do't have time to explore this further. (The reason follows). Perhaps it uses some sort of compression already.

Ah, a quick note: I've been writing articles with a very short amount of time between them, but I'll slow down - I go back to school soon. And it does take me a while to become obsessed enough about something to write a good article. :-D

Well, thank you for sticking with me through this long rant. I have enough of my thoughts, what I'd appreciate are YOUR thoughts! Let's see....

  • Would Calculator Encryption be a useful, or worthless idea?
  • Where else could Calculator Encryption be used?
  • What other programs would be useful or worthless?
  • Would the General Purpose Compressor be useful or worthless?
  • What could the General Purpose Compressor be used in?
  • Anything else?

  Reply to this item

Need for Encryption
DW

I do not see a need for strong encryption in most cases. A teacher most likely will not try to break the code, so simple (small) programs that substitute one letter or number for another will do in most cases. Even sequentially moving letters out of place could work. Simple programs will work for most people. If you know people who will spend countless hours breaking codes, go ahead and make strong encryption programs. There is little use for encryption in the classroom if it is used to prevent punishment. If you are caught it does not matter if the message is encrypted or not: you will probally get into trouble. The only need for encryption on calculators is for fun and the enlightment of the programmer. There is little practicle use unless someone creates a way to make strong encryption almost as fast and almost as small as no encryption. Unless something like pentiums are put into calculators, I don't think calculators can be used as "code machines" instead of computers. Those are my thoughts. Have fun programming.

Reply to this comment    4 September 1998, 19:09 GMT


Re: Need for Encryption
Cal Folds (LoStCauSe

I agree, but you must admit that it is cool. I made a simple Encryption program once, I was going to use it to cheat on a test :) don't worry though, I had a morals attach (I know I should look that word up, but you know what I ment if its spelled wrong)and didn't use it. The code I used might help you guys any way. I just converted the message to binary, and I transfered it to a picture, 0 is off and 1 is on (of course) for the pixels. It was very simple, made neat paterns on the screen and know one knew how to break it, to make it in crypted you would only have to do a compair with a key letter or several I guess.

Reply to this comment    6 September 1998, 02:24 GMT

Re: Re: Need for Encryption
S.T.L.
(Web Page)

To the poster a couple back: The TI-92 Number Theory Library is sufficiently fast enough to encrypt a short string in 5 seconds, much longer strings in 30 seconds. Uh oh, there goes my computer. Gotta reboot.

Reply to this comment    6 September 1998, 05:10 GMT


Re: Re: Need for Encryption
snb  Account Info

attaché
meAnt
transferRed
patTerns
compaRE

Reply to this comment    22 December 2002, 00:50 GMT

Re: Article: "Calc Crypto and the GPC"
Quantum

As for compression.....odds are that it won't be that useful because of the speed tradeoff. Encryption would be very useful....would have to be ASM to be practical tho.

Reply to this comment    4 September 1998, 20:06 GMT

Re: Re: Article: "Calc Crypto and the GPC"
S.T.L.
(Web Page)

Calculator Encryption, at least programmed by me, will not come out in assembly. The number theory functions I will be using will only come in TI-Basic.

Reply to this comment    5 September 1998, 01:22 GMT

Re: Re: Re: Article: "Calc Crypto and the GPC"
Nathan Ernst

I guess I just don't get it. ANYTHING that can be done in TI-BASIC, by defintion has to be able to be done in assembly. This is because anything executed in BASIC is converted by the calc to usable code in assembly, because that's the ONLY language the calc really understands. While you claim to be a nerd, why not let the other nerds here have a shot in assembly (If you only want to do it in basic) If nothing else; programming in assembly for the most part assures complete secrecy in the program code. If someone really wants to get ahold of it, all they'd need to do is copy whatever you encrypted over, copy the encryption program to their calc, and then send it to their computer with the Graphlink, and look at the basic source in the window. Being able to view the program would make cracking the code ALOT easier to do. Within an assembly encryption, it would denifitely be faster than basic, and people would have to go to alot more extremes to view the program code, having to reverse-compile (or decompile or whatever you want to call it) the program. Also, deciphering asm source code is a wee bit harder than figuring out how a basic program works.

Why don't you tell us what the algorithm is (because if you write your program in BASIC, we'll eventually be able to get it anyway if you post it on the 'net)?

Sorry for my babble

Reply to this comment    9 September 1998, 06:19 GMT


Re: Re: Re: Article: "Calc Crypto and the GPC"
Nathan Ernst

I guess I just don't get it. ANYTHING that can be done in TI-BASIC, by defintion has to be able to be done in assembly. This is because anything executed in BASIC is converted by the calc to usable code in assembly, because that's the ONLY language the calc really understands. While you claim to be a nerd, why not let the other nerds here have a shot in assembly (If you only want to do it in basic) If nothing else; programming in assembly for the most part assures complete secrecy in the program code. If someone really wants to get ahold of it, all they'd need to do is copy whatever you encrypted over, copy the encryption program to their calc, and then send it to their computer with the Graphlink, and look at the basic source in the window. Being able to view the program would make cracking the code ALOT easier to do. Within an assembly encryption, it would denifitely be faster than basic, and people would have to go to alot more extremes to view the program code, having to reverse-compile (or decompile or whatever you want to call it) the program. Also, deciphering asm source code is a wee bit harder than figuring out how a basic program works.

Why don't you tell us what the algorithm is (because if you write your program in BASIC, we'll eventually be able to get it anyway if you post it on the 'net)?

Sorry for my babble

Reply to this comment    9 September 1998, 06:22 GMT


Re: Re: Article: "Calc Crypto and the GPC"
Rejun2000  Account Info
(Web Page)

Arg!

People need to realize that decompression would NOT slow down a program in any way, the only slow down would occur at the launch of a program.

And the slow down wouldn't be too bad at that, remember when you run a program the ENTIRE program is copied to '_asm_exec_ram' (in the 86 at least), you just have to tack on some extra time for decompression. The extra time would be small because unlike decryption (which is time consuming), decompression relies on a small repeating pattern which is quickly processed.

And if you can't wait an extra second (probably less than that) to get 1.5x (2x is a myth) the memory on your calc, then you don't deserve the memory you already have.

-Rejun
Thanks

Reply to this comment    13 July 2002, 00:39 GMT

Re: Article: "Calc Crypto and the GPC"
Rob

Actually, these ideas are great. I had these ideas when I first got my TI-92 like 2 years ago. About 2 months afterward (it was February, and I was bored) I actually went through with creating such things (in BASIC of course). I used the best point-2-point transfer for the encryption and a simple Huffman compression, but normal people didn't understand it, and if they knew it was Huffman, they could probably decode it in a matter of minutes. This was too simple, I thought, so I used an encoder to code any of the variables (that BASIC could access) into a simple string. The string alone saved a couple bytes to even saving 100 bytes on a picture one time. I used a non-correlating compressor (no encryption uses this type except mine because I'm the only one who knows how to do it--) to change the string into another string which would turn out to be super-encrypted (super meaning the best you could get using number theory, closing zeta loops, and pi-sin algorithms). In doing this encryption it only added about a max of 25 bytes (the keys were set by the user and always a 8 pin number). The compressing program was upgraded to using a Huffman, Shannon-Fano, and Ziv-Lempel-Welch, and if the compressor ended up being bigger than the original, it encoded it using more number theory and trying the compressor again. In doing this process, it compressed around 40% to 60%. The BASIC programs (1 encrypt/decrypt and 1 compress/decompress/zip) were actually compressed themselves on a simple huffman code, run by 1 program, "RCfiler." The program itself was around 1k of memory, and used Local variables to decompress and run the programs (meaning they were always compressed unless you ran RCfiler).

I then thought "maybe if people saw the code and started 'hacking' they could decrypt messages," so I got one of my friends, who knew as much as I did about the program as I did, to decrypt a simple message "Hello" under a simple key "00000000," and gave him about a week to decrypt it. He did figure it out through a number-runner (by running the program and given stepped numbers). So, I upgraded one last time, the program now contained a 3 run only lock on it (meaning if you ran the decryptor 3 times without the correct code, the calculator wouldn't accept anymore decryptions on that file). Since I stored the times inside the file itself, copying it wouldn't do any good. He tried one more time, and got no where (of course I changed the key to "29385328"--I remember it because it's my student number at school). The time it takes was fairly slow, but remember, this was in BASIC and on a calculator.

I figured this would be great, but when I tried to find something to use it for, I came up empty. The files are compressed, but in order to use them they must be decompressed. The time it takes plus the amount of space you need for both the decompressor program and the file to decompressed was kind of like an ironic twist. I would be glad to send up some programs, but since I have no graphlink, I can't right now. I would also be glad in helping anybody who wants to start on this project out. Contact me for some code only if you're really interested (I will only teach you, I will not give out direct code--I do program for a living you know).

Reply to this comment    4 September 1998, 20:09 GMT

Re: Article: "Calc Crypto and the GPC"
ffolkes

Let's face it, people--mostly kids in high school or some other level of education want to encrypt messages.....simple messages--notes, not a top-secret government CIA document that requires incredibly high encryption. A simple scrambler would suite it well.....The opposer who wants to read it is probably just going to say "Hey, lemme see that!....what the heck dude? It all screwed up...nevermind!" Not "Lemme take that back to my top secret lab so I can work for weeks decoding it." Bottom line: It should be simple.

Reply to this comment    5 September 1998, 07:19 GMT


Re: Re: Article: "Calc Crypto and the GPC"
S.T.L.
(Web Page)

Why, I know if I were confronted with that, I would get a copy of the program, and proceed to make a cracker. Then I could read everything. :-D

Reply to this comment    5 September 1998, 20:13 GMT


Re: Re: Re: Article: "Calc Crypto and the GPC"
snb  Account Info

after you started reading it, they would change the code you dipshit

Reply to this comment    22 December 2002, 00:55 GMT

Re: Article: "Calc Crypto and the GPC"
tobt4josh

THe ti-89 still has no shell(because ti hasn't released any info yet), but putting compression into a shell would be a great way to start out for the new calc.

Reply to this comment    5 September 1998, 20:58 GMT

Re: Calc Crypto and the GPC
Brian Sipos  Account Info

I could probibly take a few days to write an RSA (public-key encryption) program in ti-89 basic. I have written one for mIRC script, and it is only limited by how large the program (calculator)'s integer limit is (mIRC can only sucessfully deal with up to 26 bit numbers, so there's a 26 bit key limit). The only thing about this is that the patent for RSA (which should never have been given a patent in the first place, because it was developed with government funding at MIT) expires on september 20, 2000. If any ASM programmer would collaberate with me, I could explain exactly how the algorithms work.

Reply to this comment    26 October 1999, 21:49 GMT

Re: Article: "Calc Crypto and the GPC"
betterthanu187

I think that a good calc crypt would be fairly useful...at least at my school because my math teachers do check calculators for cheat sheets. Its a calculator however so it probably wouldn't be like a 256-bit code (at least not on a TI-85)
I think an encryption prog would be really great if you could convert a string of text into an encypted message and then into a pic becuase I don't think that anyone would (especially my teachers)look for a pic. I anyone has any program for any calc already I'd really appreciate it if you sent the prog or at least the source code this way .I also think that a compression program would be really great epecially if it was applicable to assemble code.
P.S. I think

Reply to this comment    7 September 1998, 17:00 GMT

Re: Article: "Calc Crypto and the GPC"
David Yenoki
(Web Page)

Well, I must admit to have programmed an encrypting program (actually two, one to handle the decryption), on my TI-83. The first three releases were buggy, and quite limited in what they could do.

However, EncG4 works. My only problem is that it's slow. So very slow. It does compress, and the encryption method is of my own creation.

I have no idea how normal people encrypt things. Whatever this "number theory" thing is. My creation uses base conversions to facilitate compression between (oh say base 29) and a larger keyed base, whatever that might be. My program is most likely unique, as it will encrypt messages containing quotation marks. That's right, a quotation mark embedded within a string.

If anyone could please inform me how to research the gibberish presented for the compression and encryption methods, it would be much appreciated.

ASCII is irrelevant.

Reply to this comment    7 September 1998, 21:06 GMT

Re: Article: "Calc Crypto and the GPC"
David Yenoki
(Web Page)

Well, I must admit to have programmed an encrypting program (actually two, one to handle the decryption), on my TI-83. The first three releases were buggy, and quite limited in what they could do.

However, EncG4 works. My only problem is that it's slow. So very slow. It does compress, and the encryption method is of my own creation.

I have no idea how normal people encrypt things. Whatever this "number theory" thing is. My creation uses base conversions to facilitate compression between (oh say base 29) and a larger keyed base, whatever that might be. My program is most likely unique, as it will encrypt messages containing quotation marks. That's right, a quotation mark embedded within a string.

If anyone could please inform me how to research the gibberish presented for the compression and encryption methods, it would be much appreciated.

ASCII is irrelevant.

Reply to this comment    7 September 1998, 21:16 GMT

Re: Article: "Calc Crypto and the GPC"
Bob Vila

IT IS A FU... err.
IT IS A STINKING CALCULATOR!!! IT DOESN'T NEED ENCRYPTION!

Reply to this comment    8 September 1998, 20:46 GMT

Re: Article: "Calc Crypto and the GPC"
Josh

General purpose compression would be extremly useful for many things.. A simple method of compression could 'stack' more than one variable into a single variable, and with variable names like 'BIGVAR' containing a string like "A".. the variable's header in memory would be larger than the string..

As for encryption.. unless your 'passing notes' in a class where the teacher has contributed more to this discussion than most people, a simple method would be useful.. just take the value of the character and increment or deincrement it by a set amount.. a key, if you will..

My 2 cents..

Reply to this comment    21 September 1998, 02:17 GMT


Re: Re: Article: "Calc Crypto and the GPC"
Olathe  Account Info
(Web Page)

That would be incredibly easy to decrypt.

Reply to this comment    19 August 1999, 10:57 GMT

1  2  3  4  5  6  

You can change the number of comments per page in Account Preferences.

  Copyright © 1996-2010, the ticalc.org project. All rights reserved. | Contact Us | Disclaimer