Safeguarding all your passwords with the TI-99/4A

[Omega-TI]

As some of us age we get a 'little forgetful', and some of us have a hard time remembering 20-50 different passwords for different Internet websites, let alone the password changes, especially for those sites we may only use once or twice a year.  Well, keeping our passwords out of prying eyes is important.  One thing I like to do, is keep them all on the TI.  Why?  Well, no one can worm their way in over the Internet to steal them.  Sure, you could keep them on a USB stick and only use it on your PC when you need it, but hey, giving the old TI something to do other than playing games is good.  Now the TI's encryption program gives us a little added protection on top of putting them in a place most people would never look for them, but I have to wonder, how safe is << THIS PROGRAM >> anyway?  Has anyone ever tried to crack it's encryption scheme?  Did they succeed?

[+Lee Stewart]

7 hours ago, --- Ω --- said:

Now the TI's encryption program gives us a little added protection on top of putting them in a place most people would never look for them, but I have to wonder, how safe is << THIS PROGRAM >> anyway?  Has anyone ever tried to crack it's encryption scheme?  Did they succeed?

 

Is this possibly a version of John A. Johnson’s program of the same name that encrypts/decrypts Geneve MDOS programs? If so, that ALC source is available on WHTech.

 

...lee

[Omega-TI]

15 hours ago, Lee Stewart said:

 

Is this possibly a version of John A. Johnson’s program of the same name that encrypts/decrypts Geneve MDOS programs?

I dunno, I don't own a Geneve.

[+InsaneMultitasker]

If memory serves correctly, the Geneve  "encryption" is a simple XOR of each byte in the file.  When the OS loads an 'encrypted' program it is therefore a simple operation to 'decrypt', requiring no key or special computations.

[+Lee Stewart]

4 hours ago, InsaneMultitasker said:

If memory serves correctly, the Geneve  "encryption" is a simple XOR of each byte in the file.  When the OS loads an 'encrypted' program it is therefore a simple operation to 'decrypt', requiring no key or special computations.

 

You may be right, but from my quick look (probably too quick) it looked as though it uses XOR as only one operation, it starts with a specific 16-bit value (A006h, I think) that gets periodically incremented during processing. It also performs a circular right shift (5 bits, I think) as part of the process. I did not look at much more of the logic. The beginning key could be changed, but that would likely require re-assembly—I do not think it is a runtime option. I should look at it again to make sure the increment was to the key and not the program walking through the file.

 

...lee

[+InsaneMultitasker]

18 minutes ago, Lee Stewart said:

 

You may be right, but from my quick look (probably too quick) it looked as though it uses XOR as only one operation, it starts with a specific 16-bit value (A006h, I think) that gets periodically incremented during processing. It also performs a circular right shift (5 bits, I think) as part of the process. I did not look at much more of the logic. The beginning key could be changed, but that would likely require re-assembly—I do not think it is a runtime option. I should look at it again to make sure the increment was to the key and not the program walking through the file.

 

...lee

Quite possible and likely.  JJs de/encrypt program made the encryption mostly irrelevant but for backward compatibility, the routine remains in the OS.  The simple XOR process may be related to a different program that was written to obscure title screen and credits, thus thwarting people's efforts to edit out program credits, authorship, copyright, etc.