encrypt/decryptString error

Scripting Issues
#1

I am using encryptString function to add some protection to the information I read/write on the fly. But decryptString is yielding unstable results.

Here is the code I use to read / write files.

        import os, sys
        from panda3d.core import Filename, encryptString, decryptString
        password='my_password'
        myfile=Filename.fromOsSpecific(os.path.join(myDir,'temp.txt')).getFullpath()
        ## write 
        with open(myfile,'w') as tempFile:
            string=' text_to_write'
            tempFile.write(encryptString(string, password))
            print 'original message: '+string
        ## read
        string=open(myfile, 'rU').read() 
        string=decryptString(string,password)
        print 'decrypted message: '+string
        sys.exit()

Everything works fine when I run this from terminal on Mac 10.11, Panda 1.9.2, but when I pack it into p3d and run that (on the same machine) decryption fails and gives me a wonky string.

Also the code works fine on strings up to a certain length, for instance string1 works and string2 breaks:

string1='aux_values*4,0,0.5,0.5*'
string2='*aux_values*4,0,0.5,0.5*aux_values*4,0,0.5,0.5*aux_values*4,0,0.5,0.5*aux_values*4,0,0.5,0.5*aux_values*4,0,0.5,0.5*'

Here is log:

original message: *aux_values*4,0,0.5,0.5*aux_values*4,0,0.5,0.5*aux_values*4,0,0.5,0.5*aux_values*4,0,0.5,0.5*aux_values*4,0,0.5,0.5**
:prc(error): Error decrypting stream.
decrypted message: *aux_values*4,0,0.5,0.5*aux_values*4,0,0.5,0.5*aux_values*4,0,0.5,0.5*au‡e§9¸­³-F6lÄB,ly%á¦CeßgáúÀԔ ¤Ðt
:AppRunner: Normal exit with status None.

Any idea what I’m doing wrong, or if this is a bug, or if there is a maximum length that decryptString works on (that encryptString does not have)?

#2

A quick guess could be that it is due to an error in the character encoding?
I haven’t looked into it, but maybe try to force the encoding while encrypting/decrypting?

#3

I can’t seem to reproduce this. Could you give me the exact steps needed to reproduce it?

Though that said, an encrypted file is always binary, so you should load it with ‘rb’, not with ‘rU’.

#4

Thanks for the advice guys, I changed flag to ‘rb’ and used unicode on strings(or should I do it some other way?) The decryption works about 1 out of 5 times for the string in code below. But generally the longer the string the more often it fails, so if you don’t see error still maybe a longer string will do? For me a short one like “aux_values4,0,0.5,0.5*” does not fail at all.

main.py:

from panda3d.core import Filename, encryptString, decryptString
import os, sys

myDir,fileName=os.path.split(os.path.abspath(__file__))
myfile=Filename.fromOsSpecific(os.path.join(myDir,'temp.txt')).getFullpath()

password=unicode("my_password")
string=unicode("*aux_values*4,0,0.5,0.5*aux_values*aux_values*4,0,0.5,0.5*aux_values**aux_values*4,0,0.5,0.5*aux_values**aux_values*4,0,0.5,0.5*aux_values**aux_values*4,0,0.5,0.5*aux_values**aux_values*4,0,0.5,0.5*aux_values*4,0,0.5,0.5*aux_values*aux_values*4,0,0.5,0.5*aux_values*4,0,0.5,0.5*aux_values*aux_values*4,0,0.5,0.5*aux_values*4,0,0.5,0.5*aux_values*4,0,0.5,0.5*aux_values*4,0,0.5,0.5*")

with open(myfile,'w') as tempFile:
    tempFile.write(encryptString(string, password))
    print 'original message: '+string

with open(myfile,'rb') as tempFile:
    string=decryptString(tempFile.read(),password)
    print 'decrypted message: '+string

sys.exit()

Just this one file packaged with an empty init.py into p3d by:

packp3d -o myDirectory/testWrite.p3d -d myDirectory/testWrite
#5

Ah yes, I can see that. But when I change the ‘w’ to ‘wb’ mode, since you are writing binary data, it stops producing garbled data.

#6

Wow it was that simple. Thanks rdb!

Probably a rookie question - according to docs.python.org/2/tutorial/inpu … ting-files,
on posix there should be no difference between wb and w, what made the difference when I run it from terminal vs a packed p3d?

#7

Good question. It probably has to do with the way panda’s virtual file system reads files from mounted multifiles.

The VFS-based file open interface has been radically changed since 1.9, so I think this may no longer become an issue in future versions.

#8

I also encountered the same problem