If I remember, Base64 encoding produces a sequence of characters that are limited to only printable characters, no? And neither reversing, nor ones-complement will change the character frequency of the resultant cyphertext, so it's not much better than an ordinary substitution cypher. Combine it with the rotating-key XOR to cause the output range to include a more well distributed set so as to deter easy substitution hacks.
On Apr 15, 2007, at 5:21 PM, Arnaud Nicolet wrote: > Le 15 avr. 07 à 18:11 Soir, Lennox Jacob a écrit: > >> I have done it with encoding/decoding and I have used file.locked >> to save the file in a locked state so that its contents cannot be >> altered unless unlocked, and hopefully the file cannot become >> corrupted, again unless if unlocked. > > Well, I think you should not do that. It's probably written in the > Apple Interface Guidelines or so, but if the user didn't wanted (or > does not know) that the file is locked as soon as it is created, he > will be annoyed when he moves the file to the trash and empties it. > At least, I would. > > In my opinion, I would simply use EncodeBase64, revers the resulting > string (like "abcd" becomes "dcba") and then changing the ascii value > of every character to the inverted one (ascii 0 becomes ascii 255). > Writing to a binary file, not a text file, of course. > _______________________________________________ > Unsubscribe or switch delivery mode: > <http://www.realsoftware.com/support/listmanager/> > > Search the archives: > <http://support.realsoftware.com/listarchives/lists.html> _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
