![]() |
|
Just another Perl shrine | |
PerlMonks |
Re: Can I do secure memory management in Perl scripts for cryptographic applications?by shmem (Chancellor) |
on Jan 19, 2007 at 21:29 UTC ( #595604=note: print w/replies, xml ) | Need Help?? |
Heh... I've done just that some time ago; we have a CSV file with
customer data / emergency passwords that gets mailed around to the
response team, gpg encrypted. I wrote a Tk app to retrieve that
information and display it, since there was no other tool at hand
but the shell, gpg, tar etc. It's an ugly quick hack meant
to be fired up only in case of urgency. It spread through the company,
and there was much discussion concerning safety, memory latency, swap
impregnation and so on...
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}
In Section
Seekers of Perl Wisdom
|
|