What should the program be called?
PassLock
 0%  [ 0 ]
Cryptor
 60%  [ 3 ]
Cryption
 40%  [ 2 ]
SafeLock
 0%  [ 0 ]
PassMngr
 0%  [ 0 ]
Password
 0%  [ 0 ]
Total Votes : 5

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:

"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789thetaalphabetagammadeltaepsilonlambdamupirhoSigmasigmatauPhiOmegaintegralxmarkplotsquareplotcrossplotdotsmallT^^3squareroot^^-1^^2|<^^o^^r^^T<=!=>=~|Esmall10uparrowdownarrow !?#%&'()*+,-./:;<\=>@\[]^_`{|}|~...$ÁÀÂÄáà âäÉÈÊËéèêëÍÌÎÏíìîïÓÒÔÖóòôöÚÙÛÜúùûüÇçÑñ^^'^^`^^:[phat][recursiven]|u[|>]bolduparrowbolddownarrow|?|![xbar][ybar]^^x[<|]chi[|F][e]|L|Ninvertedequalmathprintbox ->Str3
Lbl M
ClrHome
Menu("Cryptor","Encrypt",1,"Decrypt",2,"Quit",Q
Lbl 2:~1
Goto 3
Lbl 1:1
Lbl 3:Ans->A
Input "Text=",Str0
ClrHome
length(Str0->Z:" ->Str1
"De
If A=1:"En
Repeat K=int(K) and K>0 and K<9999999999
   Input Ans+"cryption Key=",K
End
K->rand:150->X:For(X,1,X:rand:End
ClrHome
"De
If A=1:"En
Disp Ans+"crypting..\.
length(Str3)-1->L
For(Y,1,Z
   ArandInt(1,L)+inString(Str3,sub(Str0,Y,1
   Ans+~AL(Ans>L or Ans<1
   Str1+sub(Str3,Ans,1->Str1
End
sub(Ans,2,Z->Str0
ClrHome
"De
If A=1:"En
Disp Ans+"crypted [|>] Str0","Key=
Output(2,5,K
Output(4,1,Str0
Pause
Lbl Q
ClrHome:Return


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 log2(1010)≈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).
Zeroko wrote:
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 log2(1010)≈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
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement