tmpfs for key generation

[defunctio]

In my mind Algo is not really designed to persist. When you spin it up when you need it and tear it down when you are done. When you need it again you spin up a new instance, with new keys.

If everyone agrees that statement aligns with the goals of Algo I propose we use tmpfs as a memory resident only storage of sensitive keys as a layer of protection against postmortem forensics analysis that could be used for key recovery if the image were ever recovered. While this may be an unlikely event, the level of effort to implement is minimal.

[FiloSottile]

If the keys move to the client side to fix #75, you might want this for OS X

#!/bin/sh
ramfs_size_mb=$2
mount_point=$1

mkramdisk() {
  ramfs_size_sectors=$((${ramfs_size_mb}*1024*1024/512))
  ramdisk_dev=`hdid -nomount ram://${ramfs_size_sectors}`

  newfs_hfs -v 'ram disk' ${ramdisk_dev}
  mkdir -p ${mount_point}
  mount -o noatime -t hfs ${ramdisk_dev} ${mount_point}

  echo "remove with:"
  echo "umount ${mount_point}"
  echo "diskutil eject ${ramdisk_dev}"
}

mkramdisk

[mrphs]

In my mind Algo is not really designed to persist. When you spin it up when you need it and tear it down when you are done. When you need it again you spin up a new instance, with new keys.

Well, that only works for single user instances. If you continue to need it on a daily basis and have a bunch of users, you just keep the one you brought up in the first place. Spinning up new instances and re-sharing the config files makes it inconvenient.

[dguido]

Since we're moving keys to the client side, this should become a config option. The default behavior will be to generate keys in a tmpfs on the client and throw them away when done. If the user says they need the keys for later, then we will copy the keys out of the tmpfs before destroying it.