in reply to Re: Re: Handling encryption safely
in thread Handling encryption safely
I can't see ANY reason why overwriting the value in a scalar with the same number of bytes should EVER change to the situation where Perl is reallocating memory and doing a copy every time. This would be inefficient and is completely unnecessary.Just because you and I can't see a reason why it should copy doesn't mean it will not. I can't see a reason why sendmail should overflow buffers, and I don't think the author(s) ever had any intentions it should. But it has happened in the past, and I won't guarantee it will not happen again in the future.
Requirements may change. Ideas may change. Design principles may change. Mistakes may happen. Basing security on "that would be illogical" may work on Vulcan, but not here.
As noted before physically securing the box is to my mind far more important. Just look at the banks for example. How many root kits are there that let you escalate user level privilege to root whereby you can just read the script/config without having to go to the extent of trawling through memory?Wearing safety belts in a car is more important than having a fire extinguisher in a car. But that doesn't mean that if you decide to buy a fire extinguisher it's unimportant how well it works, and how to mount it in your car.
Furthermore, there are cases where it is important to protect yourself from people with root permission that you can't or won't trust. PGP for instance. Sure, it is possible for someone to replace a kernel to do whatever they want to do, but that is far more difficult than trawling /dev/kmem.
Abigail
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: Re: Handling encryption safely
by tachyon (Chancellor) on Oct 29, 2003 at 12:34 UTC |