Kaz,
In my opinion, the password entry dialog is not usable for long phrases, and encourages poor passwords. A checkbox to render the contents visible would be very useful to catch typing mistakes. It is frustrating to be told five times that the two do not match. Not everyone can touch type a long sentence twice with no mistakes.
What I do if I have a really long key is just copy and paste it into the dialog box. I agree that a checkbox to allow one to see the password would be interesting.
The security in concealing password entry is dubious anyway. It has value for protecting authentication passwords in places where someone may be looking over your shoulder. But would you be working with a highly sensitive document (that is worth protecting with AES) in such an environment? Its contents are as secret as the password used to protect it, and so it makes no sense to conceal the password from prying eyes, yet reveal the document.
I don't agree with that opinion. There are many environments where prying eyes exist. It's reasonable to take this kind of precaution. Clearly, it's not perfect. Someone might be able to watch your keystrokes. Or, in the case where I copy/paste a long string, there might be a camera recording what's on the screen. Still, it's better than having nothing at all.
Another issue with the Windows application is that it performs sanity checks in the wrong order. When you're encrypting or decrypting a document, first you must get through the password dialog. Only then are you told, oops, the destination file already exists and we must bail! There is no security benefit in this; it is just annoying behavior. Why ask for the password if the operation cannot possibly complete (unless someone deletes the file outside of the program). Just bail right away: "We cannot do this operation because the destination file exists."
Yeah, it can be a bit annoying to not see the file was already encrypted or decrypted and you type in a long password. On the other hand, you're done: the file you want is already there, so you don't have to do it again.
A useful behavior would be to have the option to rename the existing file, or to choose a different name for the newly created file. (Deletion should be deferred to the user, who should be using a secure shred program, at least for the plaintexts).
If the file is already encrypted or decrypted, why offer to create another version with a different name? Perhaps one is re-using the same filename with different file contents?
Paul