Unusual Encryption Method

[whodat]

Here's what I figured is needed:

26 Alphabetical characters
10 Numerals
31 Symbols and punctuation
3 Control (carriage return,line feed,tab stop)

That is a total of 70. Is more than this required for ordinary text messaging? The biggest limitation is that a message with upper and lower case would be returned in upper case. For example, "34.5% Profit" when unencrypted would return "34.5% PROFIT".

I think you're missing things like é, ü and the like.

Yeah, I know, but the encryption method I proposed is only able to handle 71 ASCII characters, although they could be any 71 of your choosing.

[Z!re]

And only uppercase..

I can make an encryption that can handle any two keys of your chooise..


Anyways, the less original diversion you have, the less diverse the encryption becomes..

If you can only handle 71 keys, then the output shoulöd ONLY consist of those keys too, otherwise you break your own rules..

As, for example, chars such as: # doesent exist in your 71char table.. so, it cant be in the resulting encrypted string either..

If it can, then there's no practical use whatsoever for this type of encryption..

[whodat]

And only uppercase..

I can make an encryption that can handle any two keys of your chooise..


Anyways, the less original diversion you have, the less diverse the encryption becomes..

If you can only handle 71 keys, then the output shoulöd ONLY consist of those keys too, otherwise you break your own rules...

I stated in my original post that this was for simple text messaging, 71 keys max. There's no need to rehash that point.

As, for example, chars such as: # doesent exist in your 71char table.. so, it cant be in the resulting encrypted string either..

If it can, then there's no practical use whatsoever for this type of encryption..

If my character set is only "0123456789", are you saying I can't equate 44 with 2C? As long as the original content can be returned, there is no problem.

[rpgfan3233]

Sample decrypted conversation:
WUZZUP HOMEY
Y R U SHOUTING
IM NOT SHOUTING
UR TYPING N ALL CAPS
SO R U
WHERES THE STUPID LOWERCASE
DUNNO
I NEED LOWERCASE LETTERS THAT WAS SHOUTING
DUDE WHERES THE PUNCTUATION THIS IS HARD TO READ
I KNOW IT SUX0RZ

See what it looks like? Punctuation mixed with all caps is actually worse, IMHO. I recommend having lowercase and uppercase.

[Z!re]

And only uppercase..

I can make an encryption that can handle any two keys of your chooise..


Anyways, the less original diversion you have, the less diverse the encryption becomes..

If you can only handle 71 keys, then the output shoulöd ONLY consist of those keys too, otherwise you break your own rules...

I stated in my original post that this was for simple text messaging, 71 keys max. There's no need to rehash that point.

As, for example, chars such as: # doesent exist in your 71char table.. so, it cant be in the resulting encrypted string either..

If it can, then there's no practical use whatsoever for this type of encryption..

If my character set is only "0123456789", are you saying I can't equate 44 with 2C? As long as the original content can be returned, there is no problem.

Encrypt the encrypted string to add additional levels of difficulty to crack it..

[whodat]

Sample decrypted conversation:
WUZZUP HOMEY
Y R U SHOUTING
IM NOT SHOUTING
UR TYPING N ALL CAPS
SO R U
WHERES THE STUPID LOWERCASE
DUNNO
I NEED LOWERCASE LETTERS THAT WAS SHOUTING
DUDE WHERES THE PUNCTUATION THIS IS HARD TO READ
I KNOW IT SUX0RZ

See what it looks like? Punctuation mixed with all caps is actually worse, IMHO. I recommend having lowercase and uppercase.

you make some good ...... i just want 2 make $ & become a *


With a 71 character limit, I can add punctuation and symbols, but upper and lower case? No can do. Anyway, what's wrong with shouting. Politicians have made their livelihood with it for centuries!
:lol: :lol: :lol:

[whodat]

If my character set is only "0123456789", are you saying I can't equate 44 with 2C? As long as the original content can be returned, there is no problem.

Encrypt the encrypted string to add additional levels of difficulty to crack it..

Oh well, I think I'll put this project on the back burner for now. Your comments and criticisms were appreciated. I'm moving on to an easier task---Trisecting an angle!

[Mango]

There is no reason to limit a program's ability to encrypt to a particular subset of ascii. Go ahead and make it so that it will encrypt any data, and it is much more appealing. If you want simple (yet secure) symmetric encryption (ie, the encrypting and decrypting parties use the same password) that is easy to use and secure, there are lots of options available. Ask and I'll give you one. It compresses the data before encryption, and, given the same file at two different times, will produce different (non-related) encrypted bit-streams.

[Skyler]

it may be easier to get the ascii value of a char and perform some obscure operation on it... i.e. multiply by 2 and subtract 1; OR you could just do an XOR operation like some people do...
P.S. Neo, I like your idea with the TI-83.

[Neo]

P.S. Neo, I like your idea with the TI-83.

Too bad I was forced to clean my Ti-83 during an exam last year (no "evil" Ti programs allowed!).

I might consider re-making it... >.>