secure memory for decryption buffer

[Martin Stenberg]

On Sun, Mar 18, 2012 at 05:11:30PM +0100, Werner Koch wrote:
> There is no need for it.  GnuPG manages its passphrases using the
> gpg-agent daemon.  GPGME does not need to care about passphrases.  Well,
> there is an API for passphrases, but it is only used by old GnuPG
> versions; its use is not recommended.

It is not the passphrases I'm concerned about in this case, but the
content of the encrypted file (which in my case is a big list of
passwords).

> The use of mlock is not trivial and more or less impossible for a
> general purpose library like GPGME.  Further, the protection this
> "secure memory" provides is very questionable these days.  You are
> better off using an encrypted swap partition.
>
> Using an mlocked memory area for arbitrary sizes of data is not a good
> idea in any case.

Could gpgme not have memory allocator callbacks though, like assuans
assuan_malloc_hooks? But perhaps this is pointless if mlocks are a bad
idea anyways.

I'm very interested in knowing more about why keeping things in ram as a
protection are a questionable defence these days. Could you please
elaborate on this?

Cheers!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: </pipermail/attachments/20120318/d7489e0a/attachment.pgp>