in reply to Handling encryption safely

You're quite right.

What makes perl great is that the programmer doesn't have to worry about all the housekeeping behind the scenes like memory management. But there are some situations - and this is one of them - where you want to do memory management yourself. In this case, you want to ensure that that area of your process's memory is kept *in memory* and not written to the swap partition. You then want to zero it yourself before de-allocating it. None of which you can do in perl.

This is discussed further in the gnupg manual here.

Apparently the current implementation of perl will at least overwrite your string values in memory if you have your password in a scalar and then allocate another string value of exactly the same length to that scalar. However, this behaviour is not guaranteed in future versions. The plain-text password may have also been assigned to other temporary C variables by perl and still be hanging around in memory, and so on, so it's still not safe.

Basically, if you really need to be this paranoid, don't use perl.

Replies are listed 'Best First'.
Re: Re: Handling encryption safely
by tachyon (Chancellor) on Oct 29, 2003 at 10:02 UTC

    Apparently the current implementation of perl will at least overwrite your string values in memory if you have your password in a scalar and then allocate another string value of exactly the same length to that scalar.

    Indeed you can demonstrate this. As it happens in the example given the critical point for reallocation of memory seems to be 20 bytes (19 char string + \0) - equal or less than this and the same pointer/memory is used, more than this and a different one will appear from the realloc. Overwriting with the same length string is easy enough though and you can test for the existence of the desired behaviour as shown. If it changes in the future your test suite will pick it.

    cheers

    tachyon

    s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print