simple encryption system

[strangeChild]

This string worked in Trog's code: "ÈåçêëèïîìÄÅÉæ"
These are all single byte characters in the 128-255 range AFAIK and that seems to work in your scheme.

[edit]posted around the same time as Tester[/edit]

[RJHollins]

If only 'simple' is needed ... AND dealing with multi Arrays ...

You might consider the 'Marshal file routine' using the Raw Binary setting.

Names will generally be readable ... but there is plenty of non-readable. Depends how much 'cover' you want.

[Drnkhobo]

Hey Trog, love your little module, would you mind feeding my curiosity and explaining the Ruby code a bit?

[strangeChild]

Hey... I almost understand this now..

The 127 thing isn't necessary if you have this code instead:

Code: Select all

bytes = @in_string.bytes.to_a

code = @code_key

bytes.map! do |byte|
  byte = byte ^ code
  code += @code_cycle
  code -= 254 if code > 254
  byte.chr
end

output 0, bytes.join('')

This will allow any value 0-255 but Trog's version produces more scrambled strings with low values of inputs.
His actually works with -128 to 127 on the start code.

The binary XOR is symmetrical
a ^ c = d -> d ^ c = a
Then the c part increments with each character by the cycle part but the decode is unaffected as it too increments the same way.

[tester]

It looks that Trogs little fellow may wotk with my native letters too. Will do some more tests later.

@strangeChild - thanks for mod, will play with it too, when checking other languages.

[strangeChild]

@strangeChild - thanks for mod, will play with it too, when checking other languages.

It won't work on anything that his wouldn't work with... it just took away the restrictions on the keys.
But you wouldn't want to use 0,0 as that won't encrypt at all.

[trogluddite]

There may be one problem with "high-index" ASCII numbers, and it's also the reason that I used only 128-254 for the encryption values.
If the encryption value just happens to match the character code exactly, the result of the XOR will be zero - and the zero value is often used as an "end of string" flag - what are known as "null terminated" strings. So I chose the number ranges on purpose to avoid this from happening - though that is only guaranteed anyway for the 0-127 'standard' ASCII characters.
In my first attempt at the module, I found exactly that problem - occasionally the encrypted string was truncated by nulls - so there needs to be some safeguard against that.

Base64 would be nice to use, but it isn't included as part of the FS Ruby installation - we only have the "core" classes and methods. In fact, none of the "standard libraries" are included, except for 'Win32API'.
There was some work done before on extending the libraries, but it involved having to recompile a lot of the Ruby installation files from source. Now that VST exports are using a statically linked version of the Ruby virtual machine, those techniques may not even work any more - at least not for plugin exports.

[Tronic]

Pure Ruby
http://crypt.rubyforge.org/

[tester]

To summarize.

Trog - your module is working for ascii (which does not contains non-english letters), or for non-UTF ("half-size" if I can name it this way) codepages? Because it seems to work with polish letters (as well as FS itself).

And second question would be - this simple encoding system will work for al languages, that use such sort of "half size" codepages? I mean - will it work with everything that FS can handle via it's own stringish greenery?

Now, there is one more interesting thing. While language specific (polish) letters are not displayed correctly in string/text primitives (some sort of other strange characters instead) - they are displayed on labels and editboxes. The picture shows the output after encryption/decryption (input and output are match).

[strangeChild]

it seems to work with polish letters

It seems to work because you have happened to get lucky that the code key never exactly matched the value of the upper-ascii letter or it would encrypt to char(0) and terminate the string.