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.

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.

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.

attaché
meAnt
transferRed
patTerns
compaRE

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.

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.

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

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

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

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).

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.

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

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

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.

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.

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

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.

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.

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

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..

That would be incredibly easy to decrypt.