So recently, I've made a text encryption program (that actually works) recently called Cryptor.
It uses rand as a seed, and X for the randomizer. (but in this version, I've made the default randomizer to 150 so the user doesn't have to memorize two different numbers)


Code:


So far, what do you think of it? It's pretty simple, I'm sure you could shave about 100 bytes by getting rid of all the extras, but the program is pretty small.

What type of encryption is this? Is this effective and can be cracked easily?
I was thinking of making a username and password manager for monochrome and the color editions.

The core idea is a reasonable one—adding a random value to each character in a string. If the random values were truly random, this would be a one-time pad, which is information-theoretically secure (meaning, you cannot get any information about the input from the output if you do not have the key), but then the problem would be that the key would need to be as long as the data. It seems sensible to hope for a way to expand a short key into a suitable random stream, but your implementation has at least three issues.

The first is that the random number generator in TI-BASIC is not cryptographically secure, so someone could figure out the key from any long enough encrypted text, under the plausible assumption that the input were English text (or with knowledge of what sort of text it was, at any rate). This would remain true regardless of how long the key was, even ignoring the fact that there is a limit to how large a seed rand can use in the first place.

But even without any such fancy cryptanalysis, the second issue is that your key space only allows about log₂(10¹⁰)≈33.2 bits, so the key could easily be brute forced on a computer. People have reimplemented the RNG in C, so it would not have to rely on emulating a whole calculator with TI's slow BASIC implementation. Overall, I suspect it might take a few hours to crack with unoptimized code, or maybe a few minutes or less if implemented using a GPU.

The third issue is that you do not reset the seed at the end, so if you find an encrypted string made with this program on a calculator, by far the easiest & fastest way to crack it would be to get the current seed value & then (again, on a computer) run the RNG backward (in case some other program had run afterward) until the right seed is found. This should take at most a few seconds with unoptimized code. But again, even if you do reset the rand seed, finding it via cryptanalysis or brute force is still not that hard.

The problem with cryptography is not making something you cannot break...the problem is making something that nobody else can break. Which is why people recommend only using algorithms that have been used a lot in practice without being cracked, & using well-tested implementations (to avoid flaws like the aforementioned seed leak).

One thing I will point out, I do use characters/tokens that are only familiar to the calculator’s OS, so trying to decrypt those same garbled characters might have issues on a modern computer, but what do I know lol

Might work, might not