Definitely do NOT depend on the on-screen keyboard!
IMHO the way that works best is to type your passphrase out of sequence, using the mouse to reposition the caret. A password like "gromit99wallace32" might end up as a keystream of "tgrallce3mio99wa2". It *IS* annoying to do this though, especially because the password input field is masked...
And it's not foolproof, if the keylogger places some API breakpoints rather than just snooping raw keys, it can easily get the "pieced-together" final passphrase.
There's a couple of solutions that could be applied.
1) Kernel-mode driver code (could also solve the page-to-disk problems)
Too much work and bother. Requires different drivers for 9x/NT/64bit. Not suitable for use on limited user accounts and usb flash drives.
2) Custom control for keyboard input.
Requires *some* work and would add a bit of bloat, but is doable. Still requires the "shuffled" way of inputting data, but at least it would overcome the "breakpoint on GetDlgItemText" problem.
3) Some additional "visual clue".
If you had to, say, pick three colors from a 16-color palette in addition to your passphrase, then a generic keylogger wouldn't give all the data necessary to open the file (unless it also logged client-relative mouse events, *sigh*). A targetted attack would still be possible, though.
