Here's another....file I/O difficulties.

[Moneo]

Stylin:

The new code now works fine, matching the Winer encrypted text. Nice job, and nice explanation.

The business of chr$(0) terminating a string in FB, is a sticky wicket. Others who have not considered this, like you have, could have problems with strings whose bytes can be modified by bitwise operations. The worst part is that they may work most of the time and then suddenly...
*****

[Zack]

Thanks for the explanation.
I remember a bit of that from C. If you ask me, FB ought to have a way to declared fixed-length strings, regardless of CHR$(0) terminators. ZSTRING*n can almost do this, but still uses CHR$(0).

[stylin]

Thanks for the explanation.
I remember a bit of that from C. If you ask me, FB ought to have a way to declared fixed-length strings, regardless of CHR$(0) terminators. ZSTRING*n can almost do this, but still uses CHR$(0).

You can declare fixed-length strings, but I think the issue here might be a bug: notice that passing a string by value (making a copy of it) acts differently than initializing a new string with a reference value (making a copy of it). I'm going to ask @ fb.net and see what the deal is.

[stylin]

Sorry for the double-post.

For those interested: How strings get passed by value

So, it seems that null-spersed-strings passed by value get truncated "by design", since a pointer is passed instead of the descriptor - which means we no longer have explicit length information; length must be determined incrementally - thus the truncation.

Moral of the story: for strings that may possibly contain a null character, pass by reference (if you can't safely ignore truncation). For non-modifiable strings that are guaranteed not to have a null character, pass by value, otherwise pass by reference. (if you're passing a string by reference and you don't want it modified [text, key, for example], prefer to create a local copy [result] and only use that copy throughout the function.

update: the above behavior will be changing in an indefinent amount of time . strings passed by value will be deep-copied instead of having an address passed instead. happy happy, joy joy

[stylin]

Zack, you've gotten me hooked on neat little encryption methods. Here's one I just finished. It's sort of like a combination of your original algorithm, with Winer's. Here's the procedure:

Code:

'' original
'' ^^^
'' key^
''  key^
''   key^
''    key^
''     key^
''      key
''       ke
''        k

Basically, it works like Winer's by overlaying the key across the original, but mine overlaps the key, essentialy producing the same effect as the method you originally posted, but with the first len(key)-1 characters being encrypted differently. I'm not an expert, but I suppose that for this type of encryption you mght as well employ your algorithm, but I think the function looks neat nonetheless. Here is the code:

Code:

option explicit
option byval

function StylinizeText( byref text as string, byref key as string ) as string
    if( strptr(text)=0 ) then return ""
    if( strptr(key)=0 ) then return text

    dim as string result => text
    dim as integer resIndex = 0, resLength = len(result), keyLength = len(key)
    while( resIndex < resLength )
        dim as integer keyIndex = 0
        while( (keyIndex < keyLength) and ((resIndex + keyIndex) < resLength) )
            result[resIndex + keyIndex] xor= key[keyIndex]
            keyIndex += 1
         wend
        resIndex += 1
     wend : return result
 end function

function deStylinizeText( byref text as string, byref key as string ) as string
    return StylinizeText( text, key )
 end function

[Moneo]

Albert Einstein said:
"We need to make things simple, but not simpler".
*****

[Zack]

Wicked.
I wonder how easy it is to crack XOR encryption. I used to send my encrypted files to a buddy of mine and he'd always be able to crack them.

[red_Marvin]

If you use a key that is as long as the message I think it would be impossible.

[Zack]

Interesting...imagine encrypting a file with another file of equal length. Or a string.
I suppose the only risk would be someone getting their hands on the password string.

[DrV]

That'd essentially be a one-time pad - unbreakable encryption.  However, both parties would need to get the password, which is a problem sometimes.

[red_Marvin]

It could be a quote from a book that both parties have, and then only
have a reference as "page 57" etc. But it might be good to combine
more than one letter to make the key char so you get the whole 0 to 255
range of key character possibillities.

Also: you would perhaps want to jumble up the text in some way, so
it appears to be random chars, and not words.

Aw heck, it seems easier to just give the reciever a floppy with a normal
key on :-?  :wink:

[stylin]

What's a floppy?

[Moneo]

.....
I wonder how easy it is to crack XOR encryption. I used to send my encrypted files to a buddy of mine and he'd always be able to crack them.

Why don't you send your friend a copy of a file encrypted by the enhanced Winer algorithm? Let's see if he can crack it. My guess is that you could probably give him the encryption password, and lacking the algorithm, he still wouldn't derive the unencrypted text.

I just remembered an old encryption trick that I used back in the 1970's. I had one or more dummy characters within the password, for the remote possibility that someone got a hold of the password. The algorithm knew which character(s) were dummy and just ignored them, both for encryption and decryption obviously. Easy to implement and could cause a hacker lots of headaches. I used this for a banking communications application and never had a problem.
*****

[na_th_an]

What's a floppy?

This strange thing. I never seen one. It must be some kind of alien technollogy, or made by the commies to take over the world, or something.

I think it's explosive.

[stylin]

Definitely looks like a communist device to me. You mean it matters what direction I insert this "floppy"?