Dnia 12-02-2008, Wt o godzinie 11:59 +0100, Anders Breindahl pisze: > Hello, > > On 200802010958, Krzysztof Żelechowski wrote: > > 1. The decrypted information must not make it to any persistent medium > > Use full-disk encryption, as has been stated before. That way, you can > be confident that nothing leaks into unencrypted places, since such do > not exist in the running system.
Full disk encryption makes the system unnecessarily slow, especially if applied to swap space. I am seeking an intermediate solution for desktop computers where the amount of confidential data is small. The system as a whole should not be affected (unless, of course, it is a dedicated device, but that is another story). > > > 2. The decrypted text must not be stored in volatile memory any longer > > than it is needed. In particular, it should be converted to a > > human-viewable bitmap and the computer-readable representation must be > > immediately erased. > > That I can't understand your motivation for. I suppose you're afraid > that once compromised, your adversary can't search through memory for > certain strings. That is right. > > But he could still be monitoring your actions, and copy whatever data > you construct in RAM---including the adversary-readable bitmap. Certainly. But unless the intruder is a root-kit, it cannot run a continuous memory scan unnoticed. On the other hand, immediate disposal of intermediate data can make casual inspection harder. > > As Robert stated, many of your other requirements are void, if your > adversary gains control of your machine. Admittedly the protection will never be perfect but I would like it to be as good as can be. > > > 8. The application should be as lightweight as possible (for source > > code audit). > > Right, agreed. > > > Can you direct me to some implementation meeting these requirements? > > I wrote a such script once, that satisfies much of (the serious amongst) > your requirements. Email me personally, if you're interested. If you are so kind, or just the idea if you do not want it to be adapted and published. > > Other than that you may want to look at this vim plugin, which is along > the lines of what you seek: > > http://vim.sourceforge.net/scripts/script.php?script_id=661 > It is not because it keeps encrypted data in memory. > But I still hold that your requirements for protecting against a > system-controlling adversary are silly! :) As you wish. Regards, Chris _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
