Question

I’m using libgcrypt 1.5.0 under GNU/Linux to develop a small aes256-cbc file encryption software.

I have a doubt regarding secure memory and data swapped out to disk.

Let’s say I have this code:

char *crypto_key;
crypto_key = gcry_malloc_secure(256);

Is it useful and necessary to do also these two things?

1) to not allow that memory to be paged with: mlock(crypto_key, size)

2) To prevent the information from being written to a core dump with:

struct rlimit limit;
limit.rlim_cur = 0;
limit.rlim_max = 0;
if (setrlimit(RLIMIT_CORE, &limit) != 0) {
    /* Handle error */
}

Answer 1

Without preventing writing memory areas into the page file (or code dump), sensitive data (keys) might be left written onto disk and found by someone not intended to see/have the data. Whether it’s necessary/useful depends on application. Not doing that could leave secret keys or unencrypted data lying around on laptop’s hard drive for a long time, where somebody could then acquire the keys/data from by stealing the laptop. For private use on a physically secure computer, it might not be necessary (but is still good practice, because it’s better to prepare for anything).

You don’t need to lock the memory (allocated crypto_key) yourself, libgcrypt does it for you (assuming you initialized the library properly). It should also clear/overwrite the memory once freed.

Preventing core dump might be overkill since the original unencrypted file is likely still available on the machine, along with the keys. Depends on level of security you’re attempting to achieve. If you don’t have a dump file, you also won’t forget to delete it.

Typically the user/admin of the machine should configure the machine to not do core dumps, tool programs are not the ones supposed to change the settings (and likely cannot even do it without elevated rights).