Jump to content
IGNORED

TI-99 encryption programs


aftyde

Recommended Posts

I employ magnetic encryption on my disks :D

 

Actually, there was a guy at the Faire this year (whose name escapes me) who was taking about hashes and ciphers on the 9900. As I recall he said the encryption is not so much a problem on the 9900 but generating a key pair is pretty hard on it. I got to thinking later that if you could use a modern machine to perform the key generation, or the F18A GPU, then feed that to the TI maybe that would help.

 

Mind you, a 2048-bit key alone is 256 bytes. The entire effort definitely requires 32k RAM, but then performance would be hampered by the 8-bit peripheral bus. 16-bit 32k would help quite a bit, I believe.

  • Like 1
Link to comment
Share on other sites

Actually, there was a guy at the Faire this year (whose name escapes me) who was taking about hashes and ciphers on the 9900. As I recall he said the encryption is not so much a problem on the 9900 but generating a key pair is pretty hard on it. I got to thinking later that if you could use a modern machine to perform the key generation, or the F18A GPU, then feed that to the TI maybe that would help.

 

Mind you, a 2048-bit key alone is 256 bytes. The entire effort definitely requires 32k RAM, but then performance would be hampered by the 8-bit peripheral bus. 16-bit 32k would help quite a bit, I believe.

 

That was me at the Faire.

 

So, about a year or two ago, I wrote some assembler subroutines for the TI that can do AES-256 and SHA-256.

 

My starting goal was to develop a program that could create encrypted files on the TI that could be read by PGP (or GPG) on a PC or Mac.

 

I never got around to writing the RSA part of the code needed by PGP/GPG. The RSA part needs some big-integer mathematic subroutines. I need routines that do the following:

* Compute a random key (harder than it sounds if you want it to be "secure", eventually, I'll probably make a non-secure first version for testing)

* Then check if it is a pseudo-prime (can use the Fermet Little Theorem Primality Test).

* Need to be able to add, subtract, and multiply between arbitrarily long integers

* Need mod, modPow, and remainder algorithm for arbitrarily long integers

 

Those algorithms probably aren't too complicated to code in TMS-9990 assembly, but I never got around to them due to time constraints.

 

The other part you need, and the part I got "stuck" on, was you need to a way to protect your private key with a passphrase so that if someone grabs your disks (or Compact Flash card in your NanoPEB) they can't just grab your private key file and then use it to decrypt everything. The way you typically handle that is that you hash your passphrase using SHA-256 several thousand times, say 65,536 times or more. That way, if someone steals your disks, your encrypted private key will take a very, very long time to crack (until quantum computers that can do Shor's algorithm come around). The problem is, running SHA-256 once on a passphrase isn't too bad on a TI, but doing it a couple of thousand times is basically a non-starter. It was just too slow. Now, I never got around to trying to optimize my assembly code--there was a lot of stuff I could still try (putting registers in 16-bit scratch RAM, or even offloading the algorithm to the F18A), but again, time constraints, and I never got back to it.

 

At the Faire, people told me about the cross assemblers that are available now for the PC and Mac that let you write your assembler and compile on much faster computers. Maybe I'll give that a shot and try to get back into it. (I developed the original AES-256 and SHA-256 subroutines on an actual TI with NanoPEB running Editor/Assembler--it was very, very time consuming--taking ten minutes just to debug a couple of lines of code, and then re-assemble, and then run.)

 

Also, if there are actually people interested in this, or want to help test, then that also gives me some incentive to want to do something more with it. I thought I was the only one interested in doing encryption on old hardware.

  • Like 5
Link to comment
Share on other sites

It is even worse than that, Lee: I'm one of those crazies who actually plays with codes and algorithms for fun. . .I had a college professor who likes to use an encrypted string as half of his final grade. The object wasn't to solve the problem (he figured that wasn't possible in the time he allotted for the test), but to show how you would attack the encryption. I solved it in about two minutes--and was the only person he'd ever had in the class that could solve it. The rest of my class wasn't able to get it at all--and the only two people in the class that I considered potentially capable were ahead of me on the way out: they both asked each other simultaneously if the other one had solved it and got the slow negative shake of the head in return, so they turned to me and I told them what the unencrypted string was. They were really confused when I told them how I'd solved it, as neither of them had even considered looking at it quite the way I had. Cryptography is fun. . .

Link to comment
Share on other sites

It is.... I remember my 8th grade science teacher was obsessed with it. One day he took a two hour class and taught us some basics... Then he gave us homework to write an encryption key of our own, write a message to him with the encryption, and he would solve them all the next day during class. He got about 70% of them during that day's class and one by one, we watched him solve them, dumbfounded.

 

One kid used colored pencils and had a different color for each letter of the alphabet... That was the second or third one he solved. I used numerics, each letter in the alphabet was given a random number from 1 to 26... A was 5 I think and B was 21... I then multiplied each number by two and used those values to write k y message. He got that one too.

 

I learned alot from Mr. Parker...

  • Like 1
Link to comment
Share on other sites

I'd help test. I like the idea of offloading processing to the F18A. Other options might involve allowing the importing of keys generated on other machines. Too bad there is no USB - as crypto routines in some secure USB keys might be accessible.

 

 

 

That was me at the Faire.

 

So, about a year or two ago, I wrote some assembler subroutines for the TI that can do AES-256 and SHA-256.

 

My starting goal was to develop a program that could create encrypted files on the TI that could be read by PGP (or GPG) on a PC or Mac.

 

I never got around to writing the RSA part of the code needed by PGP/GPG. The RSA part needs some big-integer mathematic subroutines. I need routines that do the following:

* Compute a random key (harder than it sounds if you want it to be "secure", eventually, I'll probably make a non-secure first version for testing)

* Then check if it is a pseudo-prime (can use the Fermet Little Theorem Primality Test).

* Need to be able to add, subtract, and multiply between arbitrarily long integers

* Need mod, modPow, and remainder algorithm for arbitrarily long integers

 

Those algorithms probably aren't too complicated to code in TMS-9990 assembly, but I never got around to them due to time constraints.

 

The other part you need, and the part I got "stuck" on, was you need to a way to protect your private key with a passphrase so that if someone grabs your disks (or Compact Flash card in your NanoPEB) they can't just grab your private key file and then use it to decrypt everything. The way you typically handle that is that you hash your passphrase using SHA-256 several thousand times, say 65,536 times or more. That way, if someone steals your disks, your encrypted private key will take a very, very long time to crack (until quantum computers that can do Shor's algorithm come around). The problem is, running SHA-256 once on a passphrase isn't too bad on a TI, but doing it a couple of thousand times is basically a non-starter. It was just too slow. Now, I never got around to trying to optimize my assembly code--there was a lot of stuff I could still try (putting registers in 16-bit scratch RAM, or even offloading the algorithm to the F18A), but again, time constraints, and I never got back to it.

 

At the Faire, people told me about the cross assemblers that are available now for the PC and Mac that let you write your assembler and compile on much faster computers. Maybe I'll give that a shot and try to get back into it. (I developed the original AES-256 and SHA-256 subroutines on an actual TI with NanoPEB running Editor/Assembler--it was very, very time consuming--taking ten minutes just to debug a couple of lines of code, and then re-assemble, and then run.)

 

Also, if there are actually people interested in this, or want to help test, then that also gives me some incentive to want to do something more with it. I thought I was the only one interested in doing encryption on old hardware.

Link to comment
Share on other sites

It might be a use-case to build a specialized USB stack for Thierry Nouspikel's USB/SM card. There is no DSR supporting USB for it at all, other than some random experimentation Thierry and Fred Kaal did. Any DSR would have to be specific tot he USB device-type you're trying to use though, as the TI doesn't have the capability to work with a general-purpose USB driver due to resource limits.

  • Like 1
Link to comment
Share on other sites

  • 4 years later...
On 9/29/2020 at 5:49 AM, Bill Smith said:

Sorry to revise this old thread. In it @BJGuillot stated he had written SHA-256 in some assembly routines. Any chance those are available? I'm playing with a project where I need a SHA hash calculation.

 

Regards,

Bill

 

Hi Bill.  I never finished cleaning that code up.  Needed a lot more testing and enhancements.  Back when I was putting it together I was doing my actual development on bare metal with EA and it was painful.  The code kept getting corrupted on my NanoPEB's CF card.  I later started playing with development on my Mac using the Python assembler tools, but never moved the encryption code to that environment.  If there is interest, I can go look for it but it's in an unfinished and very raw state last time I looked at it.

  • Like 3
Link to comment
Share on other sites

7 hours ago, BJGuillot said:

Hi Bill.  I never finished cleaning that code up.  Needed a lot more testing and enhancements.  Back when I was putting it together I was doing my actual development on bare metal with EA and it was painful.  The code kept getting corrupted on my NanoPEB's CF card.  I later started playing with development on my Mac using the Python assembler tools, but never moved the encryption code to that environment.  If there is interest, I can go look for it but it's in an unfinished and very raw state last time I looked at it.

I'd honestly be interested in whatever you have. I've ported to various languages and platforms before, but my weakness  will be porting to a 16 bit platform. Trying to understand legacy platforms is a new experience for me.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...