The biggest problem with all this is that it's very hard to tell if everything's working like it's supposed to. How do you write a test to make sure your data hasn't been exposed to the possibility of being written to swap?

My take on that is: Thou shalt not utter passwords but inside thyself. At the moment sensitive information is on display, that display becomes a location inside thyself which thou shalt not reveal. Since that information propagates through your computer memory via X cut buffers and what not, your whole box is to be treated as being inside thyself, once a security token has been accessed. So you must keep it from utterance, and the only safe way to detach your responsibility from that box is turning it off (provided it's disks are encrypted and the swapspace is disposed of properly at shutdown).

In short, it's not a matter of memory destruction but of perception. Security is about awareness, not about a particular device, much the same as firewalls aint software or appliances, but concepts.

Even if I provide for my colleague to encrypt proper all their data with unbreakable ciphers, I cannot prevent them from shouting in the mall.

That said, your approach seems safe to me (for some value of safe ;-) which doesn't mean it could not be improved...

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Tk itself might also be problematic - this is probably true for all user interface code - say if you print to STDOUT you have no way of knowing all traces will be erased after your program is done with it.

In the end I think (on UNIX at least) you just can't protect yourself from the super user, but you'll be reasonably safe from other users by default as long as you don't write your data to accessible files / open X clients etc.

Good luck, but you have a very tough problem ahead of you. Consider the situation where the memory page containing the plain text is swapped to disk. The disk block to which the memory page was written could lay unchanged for a while. Even worse, it could be claimed by a file which only uses the start of the block, preserving all or a part of the plaintext at least until the file is deleted.

Bruce Schneier touched on this in recent blog entry and Wired article Choosing Secure Passwords. (Look near the bottom for "Forensic Toolkit".)

Well, I'm not that paranoid. I understand (as will my customers) that while the text is displayed, any rouge app/etc. that might be on the machine could access it -- if nothing else, by capturing the screen buffer.

All I'm really looking for in terms of safety is that when the cleartext display is destroyed, being reasonably certain that it's not still lurking about in some easy-to-retrieve place. I'm willing to live with it remaining in swap (encrypting swap is so damned easy these days...), but would not want it hanging about in RAM.

<–radiant.matrix–>
Ramblings and references
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet

(encrypting swap is so damned easy these days...)

and then you have that encryption key somewhere in RAM...

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Even if you switch to C, can you count on Tk to treat your data safely?

Methinks you need a copy of this and this.

What is "this" and how is it different from the other "this"? Can you give a little context for those hyperlinks? Titles would be wonderful.

Geez ... why does my snarky parade always get rained on. The *links* are to Secure Programming in C/C++ and Embedding and Extending Perl.

-derby

$ sudo sysctl -w vm.swapencrypt.enable=1
vm.swapencrypt.enable: 0 -> 1
[download]