Thanks a lot for the keywords, the hints and the missing parts. Indeed, I hoped that such an application did not need a custom implementation because IMHO encrypting information is useless if you cannot view the information without exposure to eavesdropping or tracing. I have to review what is available and what is needed before I can come up with a budget.
Specific comments below. Thx, Chris Dnia 06-02-2008, Śr o godzinie 02:22 +0100, Philipp Gühring pisze: > Hi, > > > 1. > > The decrypted information must not make it to any persistent medium > > (I understand gpg '-d' already guarantees it > > as long as it manages the decrypted text, > > but what happens after it leaves gpg?) > > Use a full-disc encryption system for all your persistent media. That is overkill if it only can be avoided. > > > 2. > > The decrypted text must not be stored in volatile memory > > any longer than it is needed. > > You can use TaintedBochs or TaintedQemu to investigate that. > > > In particular, it should be converted to a human-viewable bitmap > > and the computer-readable representation must be immediately erased. > > Doesn´t help much to try that, I would say. But feel free to try ... > > > 3. Only the information I need should be displayed. > > You need a Do-What-I-Mean system for that. In this particular case, Do-What-I-Mean means displaying only matching information à la fgrep. The keywords are not secret. > > 7. > > If more information is requested, > > it should be displayed in small chunks. > > The program should be fully unaware > > of the content of the chunks that are not being displayed. > > > (That probably means a garbage-collected language cannot be used). > > I don´t understand why you need that. > I would suggest that you seperate the small chunks into seperated encrypted > files, to ensure that the reader only gets those chunks that you actually > decrypted. I shall consider that but I do not like this idea at the first glance; I am afraid there would be some maintenance overhead. > > > 8. > > The application should be as lightweight as possible > > (for source code audit). > > Agreed. > > > Can you direct me to some implementation meeting these requirements? > > I think your specification isn´t complete yet. You forgot about half of the > requirements. > > I guess that: > > * You want a machine that seperates code from data (to be secure against > trojans, virii and other malware) > > * You want secure documents, that can´t change dynamically, or otherwise > contain invisible contents I thought GnuPG-encrypted files are immutable, aren't they? > > * You want a secure path to the user > > (and some more requirements that I forgot at the moment) > > What´s your budget for this small project? > > Best regards, > Philipp Gühring > _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
