Re: [ANN] luabcrypt

[Sean Conner <sean@...>]

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 ... )