Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Here's another....file I/O difficulties.
#31
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...
*****
Reply
#32
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).
f only life let you press CTRL-Z.
--------------------------------------
Freebasic is like QB, except it doesn't suck.
Reply
#33
Quote: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:
Reply
#34
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 Wink. strings passed by value will be deep-copied instead of having an address passed instead. happy happy, joy joy
stylin:
Reply
#35
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. Smile 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
stylin:
Reply
#36
Albert Einstein said:
"We need to make things simple, but not simpler".
*****
Reply
#37
Wicked. :o
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.
f only life let you press CTRL-Z.
--------------------------------------
Freebasic is like QB, except it doesn't suck.
Reply
#38
If you use a key that is as long as the message I think it would be impossible.
/post]
Reply
#39
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.
f only life let you press CTRL-Z.
--------------------------------------
Freebasic is like QB, except it doesn't suck.
Reply
#40
That'd essentially be a one-time pad - unbreakable encryption. However, both parties would need to get the password, which is a problem sometimes.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)