Unusual Encryption Method

[whodat]

This way the crypto will be no larger than the original text.

Well, if you think about it, wouldn't that actually be a good thing? Looking at MIME (base 64) encoding, it's useful to have something longer than the original text. I think I'll create my own encryption technique now. . .

I believe it's usually desirable to have the ciphertext shorter than the plaintext for reasons of efficiency and speed. Here we're talking about encrypting short text files rather than large media files, so I don't think it makes any difference.

Anyway, I don't think that having the ciphertext longer or shorter than the plaintext necessarily means that the encryption will be more secure.

[whodat]

I used something similar on my Ti-83.

Is that the TI-83 graphing calculator? I didn't know it had that kind of capability.

[rpgfan3233]

I used something similar on my Ti-83.

Is that the TI-83 graphing calculator? I didn't know it had that kind of capability.

The programming for the built-in BASIC syntax programming application is a bit more like Visual Basic than QB/FB, but it's not that hard to get used to. The worst part is typing everything in using the calculator keys. I think you can use a keyboard or something for it though. . .

[Z!re]

Interessting idea, too bad it can't handle the full ASCII table.

In addition, it can't handle linebreaks, so you get the exact same structure:
Hi there
This is a message

Would encrypt to two lines, of the exact same lenght..


What you could do is add a "special" char, like \, which would translate to the other ascii codes. As such:
. -> \046
" -> \034

Etc, sure, the crypto would become a bit larger than the original message, but unknown characters would be handled..

If the original message is:
Blarga\0392What

Then you simply encrypt it to:
[blarga]\[ascii code for \, always 3 digits][0392What]

It can handle 71 characters, enough for all the keys on my keyboard, providing you convert the text to upper or lower case before encrypting.

It can handle linebreaks and tab stops. You simply have to add chr$(10), chr$(13),and chr$(9) to the character set.
This way the crypto will be no larger than the original text.

You missed my point.. but nevermind..

Try encrypting a binary file, then decrypting it.. enjoy..

[whodat]

Interessting idea, too bad it can't handle the full ASCII table.

In addition, it can't handle linebreaks, so you get the exact same structure:
Hi there
This is a message

Would encrypt to two lines, of the exact same lenght..


What you could do is add a "special" char, like \, which would translate to the other ascii codes. As such:
. -> \046
" -> \034

Etc, sure, the crypto would become a bit larger than the original message, but unknown characters would be handled..

If the original message is:
Blarga\0392What

Then you simply encrypt it to:
[blarga]\[ascii code for \, always 3 digits][0392What]

It can handle 71 characters, enough for all the keys on my keyboard, providing you convert the text to upper or lower case before encrypting.

It can handle linebreaks and tab stops. You simply have to add chr$(10), chr$(13),and chr$(9) to the character set.
This way the crypto will be no larger than the original text.

You missed my point.. but nevermind..

Try encrypting a binary file, then decrypting it.. enjoy..

What point did I miss?

The focus of my post concerns only ASCII files, not binary.

[Z!re]

Code:

message$ = "Detta är ett riktigt meddelande, testar: ÅÄÖ?! 'Hmmm'"

Also, my keyboard is a 101/102 key QWERTY keyboard.. which is.. the standard..

[Neo]

I use FAR more keys than 71, even in ASCII files.

Don't forget any annotation characters like , . " ' ! @ # $... etc etc as well as the special extended characters like é å and so forth.

And yup, you missed Z!re's point.

[whodat]

Code:

message$ = "Detta är ett riktigt meddelande, testar: ÅÄÖ?! 'Hmmm'"

Also, my keyboard is a 101/102 key QWERTY keyboard.. which is.. the standard..

All I'm saying is that my scheme can handle 71 ASCII characters of your choice. That's enough for ordinary text messages for my purposes. Evidently for you, it isn't enough.

[whodat]

I use FAR more keys than 71, even in ASCII files.

Don't forget any annotation characters like , . " ' ! @ # $... etc etc as well as the special extended characters like é å and so forth.

And yup, you missed Z!re's point.

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".

[rpgfan3233]

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.