If I kencrypt a file like an xml file, and then I do it again (because I do kencrypt dir/*/*.xml) it destroys the file. I suggest that kencrypt notice if the file is already encrypted and either decrypt and re-encrypt, or simply leave it alone because it obviously has not been hand-edited. That way we can just encrypt all our new files with a line like the above. The goal is make-like functionality, encrypting only what has not yet been encrypted, and of course never destroying files at any time.
It might also be useful to set the renaming pattern for the original file. If it is always foo.xml.original and you leave those around, an attacker can guess that and get at the originals in most cases. While my xmls are machine generated, I still like to test and modify them until they are right, and then encrypt those that I regenerated in plaintext.
While I am a software tools guy and don't necessarily like combining things, it might be nice if kmaketiles could be told to generate encrypted files directly. It's more efficient for it to do that while writing than to write them out and rebuild them all again and notice who has been rebuilt. (Particularly because kencrypt can only be called from its home directory on linux but I presume that will be fixed.)
For security, it would be good if one could generate one's own key when building the private version of krpano.swf, and give this key to kencrypt. This way if the master key in krpano is compromised individual files are not. Or is our licence key tied into the encryption so that it is different for each of us? If not, that would make sense. Does the kprotected swf file have the licence key integrated into it so it does not have to keep the licence file in what is otherwise usually a public place? That would be necessary, otherwise an attacker can just get the licence key and, aside from pirating the software, also read the images if their key depends on it.
Alternately kprotect could generate a random key, and kencrypt could know to read that random key from a file.
Does decryption use significant CPU? I would hope not, otherwise people might want to encrypt only the .xml files and not the image files, counting on the locations of the images to now be weakly protected. (I say weakly because anybody with a packet sniffer or proxy can see what URLs are being fetched. Of course even the jpeg protection is not very strong as the key is sitting in the swf, but that takes a more determined attacker.)