lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Wouldn't encrypting the swap with keys that change all the time, and visible/changed by the kernel do a better job overall (at some cost)?

On 12/16/2011 5:05 PM, Sean Conner wrote:
It was thus said that the Great Sam Roberts once stated:
On Fri, Dec 16, 2011 at 9:57 AM, Michael Savage<mikejsavage@gmail.com>  wrote:
luabcrypt is a wrapper around OpenBSD bcrypt that doesn't require you to
be actually using OpenBSD.

Github: https://github.com/mikejsavage/luabcrypt

All feedback is welcome (including nitpicking over names etc) since I've
not properly released any code in over a year, so I expect I did
something wrong.

Why do you malloc small buffers with fixed sizes? Just allocate on stack:

char* buf = malloc(_PASSWORD_LEN)

   -- could be
  char buf[_PASSWORD_LEN];

etc.

Since you don't check malloc for success, it would also be more robust
not to make a library call that could fail.

   If you want to be truely paranoid about this, you may want to allocate a
memory page, lock it into memory (so it is not swapped to disk), then do the
password thing.  Once you have done whatever it is with the password, then
wipe the memory used for the password, unlock and release the page.  Under
Unix, this works:

   char *buf;
   size_t pagesize;

   pagesize = sysconf(_SC_PAGE_SIZE);
   buf      = mmap(NULL,pagesize,PROT_READ|PROT_WRITE,MAP_PRIVATE,-1,0);
   if (buf == MAP_FAILED) error();
   if (mlock(buf,pagesize)<  0) error();

   /* handle password */

   memset(buf,0,pagesize);

   if (munlock(buf,pagesize)<  0) error();
   if (munmap(buf,pagesize)<  0) error();

Passwords can be recovered from swap, so that's why you prevent the memory
from ever going to swap.  The wiping afterwards is just being cautious.  You
need to unlock the memory since there's usually a limit to how much you can
lock at any given moment.

   -spc (Some people are this paranoid ... )