__       __  __   __ __    _____    __  __   _____
   / /      / / / /  / //_/   / ___/   / / / /  / ___/
  / /      / / / /  / ,<      \__ \   / / / /   \__ \ 
 / /___   / /_/ /  / /| |    ___/ /  / /_/ /   ___/ / 
/_____/   \____/  /_/ |_|   /____/   \____/   /____/  


# SYNOPSIS

LUKSUS is a text-based menu driven program, for Linux and BSD which runs in a
terminal window or console. LUKSUS lets you encrypt your files,
hardrives, usb sticks and virtual container using your operating
system's internal encryption mechanism and acts as the frontend to the
internal encryption mechanism. 
It can use the following encryption facilities: LUKS, Truecrypt, GELI
and GNUPGP. It works on Linux, DragonflyBSD and FreeBSD. LUKSUS also
supports GNU Privacy Guard and OpenSSL to encrypt single files.


# BACKGROUND

The purpose of this script is to provide to myself, an easy way to encrypt
storage media in Linux, FreeBSD and DragonflyBSD, such as hardrives, usb sticks,
sd cards or external hardrives. It uses the LUKS and cryptsetup
crypto subsystem internal to the Linux Kernel. It can also use
Truecrypt encryption with the tcplay command, and FreeBSD's geli
encryption.

LUKSUS is a wrapper script for cryptsetup/tcplay/geli, shred and mkfs.
Instead of having to read up on the documentation for these
tools, I wrote this wrapper script to handle the proverbial heavy lifting.

Being opinionated and pragmatic this program assumes the following dependencies: dialog, gnutools / coretools , and a supported
encryption engine installed. On Linux this is either found in the
cryptsetup package for LUKS support and tcplay for Truecrypt support.
LUKSUS also supports GNU Privacy Guard (OpenPGP) and OpenSSL.

Dependencies - packages you need in order for LUKSUS to run:
   On Linux - The following packages are required:
   bash
   dialog
   cryptsetup - If you want to use LUKS
   tcplay - If you want to encrypt using truecrypt, note: tcplay and not TrueCrypt.com's package
   coreutils (depending on your distro)
   gnutools (depending on your distro) 
   
   On *BSD:
   bash
   coreutils (we need gtail and ghead, we rely on the same parameters as the Linux tools)
   dialog
   DragonFlyBSD does not ship with bash, dialog and GNU coreutils by default, so you have to install it
   from the repositories. 
   DragonFlyBSD: pkg_radd bash dialog coreutils tcplay 
   FreeBSD     : pkg_add -r bash dialog coreutils
   NetBSD      : pkg_add -v bash dialog coreutils

   an empty hardrive or storage media
   knowledge about which device the hardrive or storage
   (blkid or dmesg will provide this)
   

# USAGE

./LUKSUS
(No command line options needed, anymore)


# FREQUENTLY ASKED QUESTIONS:
Q: Why should I use this script? 
A: I wrote this script because I wanted to have a way to easily and casually create encrypted volumes.
   Because doing all these tasks manually is 
   time consuming and can be a little tricky. I wanted to have a simple
   way of creating encrypted volumes instead of having to consult
   documentation each and every time I wanted to do it.
   Also, writing this has been a great learning experience.


Q: What's in the secret sauce of LUKSUS?
This is the gist of the encryption process is these commands
(different for every engine of course):

LUKS
cryptsetup --batch-mode --verbose --key-size=512 --cipher=aes-xts-plain64 luksFormat $device $keyfile

Truecrypt (tcplay)
tcplay --create --device=$device --cipher=AES-256-XTS

Geli (FreeBSD)
geli init -s 4096 $device

Q: What are some alternatives to LUKSUS? (LUKSUS seeks to be different
than other tools)

The QT-based zulucrypt is a graphical option for when you want to use X
It's a fine tool and a good competitor :)
http://code.google.com/p/zulucrypt/

Tomb is interesting, and uses LUKSUS
http://www.dyne.org/software/tomb/

Q: Why is the AES-256 cipher used to encrypt files in LUKSUS?
A: LUKSUS uses AES-256 because it presents itself as the safest
cipher available. It has been thoroughly vetted and impossible 
to crack unless Quantum Computers become a reality.
Take a look at this for more information: 
http://www.moserware.com/2009/09/stick-figure-guide-to-advanced.html

Q: I really want to learn more about crypto in Linux. Where should I start?
A: Tom Ryder wrote a series of excellent blog posts covering Linux
crypto software and usage of these. I highly recommend reading them through:
http://blog.sanctum.geek.nz/series/linux-crypto/
Thanks a lot Tom Ryder, for these very thorough and awesome posts.

Q: Should I trust TrueCrypt?
A: I have stopped using Truecrypt altogether, the license is obscure,
and the open source code doesn't compile. Thus the binaries
distributed by TrueCrypt are possibly compiled by different codebase.
A two part code audit og TrueCrypt has been propsed, and
as of this writing, part one is complete. They found no irregularities.
Here is the website of the Truecrypt Audit project: 
http://istruecryptauditedyet.com/

Q: What is the license of LUKSUS?
A: LUKSUS is free libre open source software, released under the GPLv2
   license. Please let me know if the GPLv2 makes it hard for you to use it, and I
   will consider adding an extra license or changing it. Perhaps
   changing to MIT license.

Q: Why should I encrypt?
A: It is beyond the scope of this README to go indepth. 
   Please google/duckduckgo for more info. Read some of Bruce Schneier's excellent articles and essays.
   
   Encrypting your date gives you the power to decide
   who gets access to your data.

Q: Where have you learned from? What have is LUKSUS based on?
A: Generally LUKSUS is based on the guides provided in the LUKS FAQ, Truecrypt/Tcplay FAQ, and FreeBSD documentation:
   Cryptsetup / LUKS FAQ: https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions
   Truecrypt documentation:  http://www.truecrypt.org/docs/
   FreeBSD disk encryption documentation: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/disks-encrypting.html
   BSDTutorial: http://bsdtutorial.org/freebsd/encrypt-filesystem
   NetBSD disk encryption documentation: http://www.netbsd.org/docs/guide/en/chap-cgd.html
   OpenBSD crypto documentation: http://www.openbsd.org/crypto.html
   Stackexchange: http://unix.stackexchange.com/questions/9527/how-should-one-set-up-full-disk-encryption-on-openbsd
   OpenBSD 16 systems tips: http://www.16s.us/OpenBSD/vnconfig.txt (dead link :( )
   NetBSD disk encryption guide: http://julipedia.meroh.net/2012/02/encrypted-disk-images-in-netbsd.html
   NetBSD disk encryption guide: http://gilbert.fernandes.pagesperso-orange.fr/fullcgd.txt
   NetBSD disk encryption description: http://www.imrryr.org/~elric/cgd/cgd.pdf
   NetBSD cgd author interview: http://www.onlamp.com/pub/a/bsd/2005/12/21/netbsd_cgd.html
   Colin Barschel, Sleepyhead.de: http://sleepyhead.de/howto/?href=crypt
   
   Bash and sh guides:
   Michael Potter, Advanced Shell Scripting, http://uniforum.chi.il.us/slides/bash1.pdf
   Steve Parker, Bourne Shell Programming Tutorial, http://steve-parker.org/sh/sh.shtml
   Cooper, Advanced Bash Guide, http://www.tldp.org/LDP/abs/html/
   Greg's Wiki, BashFAQ, http://mywiki.wooledge.org/BashFAQ
   Robert Muth, Better BASH in 15 minutes, http://robertmuth.blogspot.dk/2012/08/better-bash-scripting-in-15-minutes.html
   All various Bash submissions on Hackernews: https://hn.algolia.com/?q=bash#!/story/forever/0/bash
   Google's shell script manual of style

Q: How is the script designed?
A: The script reuses code wherever possible and is heavily built
around reusable variables and functions. The main() function is the entire LUKSUS file.
   The script works like this:
   all existing data will be brutally removed beyond reconstruction (forensically)
   then it writes random data to the drive
   then creates a keyfile
   then encrypts the drive using the keyfile stored in /keys
   a LUKS header backup will also be placed in /keys
   please remember to take care of your /keys
   if you loose your /keys, the keyfile to your encrypted drive, then
   the data will be impossible to retrieve.
   (rewrite of this part scheduled)


Q: Is there a Disclaimer? 
A: Yes:
   As with all security measures: Use with caution.
   There is no such thing as 100% guaranteed security. Also:
   I, the author, take no responsibility if a black hole appears,
   and implodes your house, your town and the entire planet earth as an
   effect of using this script.
   Understand that the author takes no responsibility, and cannot
   be held liable if you, the user, use the script to destroy the
   files/contents of your storage media.
   As a consequence it is the sole responsibility of the user
   to use this software correctly. The author cannot be held
   liable for any damages, as of this disclaimer.
   Furthermore you are responsible for the content you encrypt.
   END DISCLAIMER


Q: I lost the key or the password, is there a way to restore the key
if I forgot it?
A: No. Really. No.

Q: LUKSUS is only a bash script, or a set of bash scripts. Is it robust?
A: Recent versions of LUKSUS features several failsafe mechanisms to
protect the user against its own mistakes, as well as faulty operating
conditions like broken binaries and faulty command procedures (race errors).
ERRTRAP has been set to 1 for instance.

Q: ON KEYFILES - ARE THEY BETTER THAN PASSWORDS?
A short: Depends. Keyfiles creates a flexible situation.fs
A long: Good question, some crypto wizards gave me this answer: -
(Passphrase-protected) Keyfiles are two-factor (something you have,
something you know) and passphrases are one-factor (something you
know). It should be obvious that (passphrase-protected) keyfiles are
at least as secure as passphrases because you need a passphrase to use
them. Considering you also need access to the appropriate filesystem,
they'd be more secure, if just by a little bit.
If you're talking about plaintext keyfiles, they're one-factor secure
(something you have). It's not so obvious whether a plaintext is more
or less secure than a passphrase. It would depend on the context, I
guess.
-
Keyfiles are possession factors (something you have). Possession
factors are threatened by theft and duplication. Since a keyfile is
just a file, it's relatively easy to duplicate it, so it's not a very
strong factor. In theory, a possession factor can be destroyed -- but
not if it's been duplicated or stolen!
Passphrases are knowledge factors (something you know). Knowledge
factors are threatened by guessing and discovery. A strong passphrase
that's not stored anywhere but your head is still weak against
compulsive discovery (the cyrpto wrench attack, legal compulsion, etc.).
-
Source: Reddit discussion
http://www.reddit.com/r/crypto/comments/1gnezg/keyfile_or_passphrase/

So let's take the case of David Miranda, for him it was very useful
not to have the keys: 
http://www.theatlantic.com/international/archive/2013/08/the-real-terrifying-reason-why-british-authorities-detained-david-miranda/278952/

Also the web is closing in even on longer passwords nowadays:
http://arstechnica.com/security/2013/08/thereisnofatebutwhatwemake-turbo-charged-cracking-comes-to-long-passwords/

Q: On what platforms and distributions has LUKSUS been tested?
A: LUKSUS works on Linux, FreeBSD and DragonFlyBSD.
   Tested on the distros: Debian, Ubuntu, ArchLinux, DragonFlyBSD and
   FreeBSD. Very possibly all derivatives of FreeBSD also.

Q: What license is LUKSUS released under?
A: Luksus is released under GNU GPLv2 License
   located here: http://www.gnu.org/licenses/gpl-2.0.html
 
Q: I have found a bug or have another issue, how can I report it?
A: Any issues can be reported to the Github issue tracker for
   this project, located here: https://github.com/partoneoftwo/luksus/issues
   I really want to hear from you, feedback, the ways you use it, 
   suggestions, tips and so on. 

Q: What is the LUKSUS homepage?
A: LUKSUS is maintained in a Github repository.
   The latest version can always be downloaded
   from the GITHUB page, see the TAGS to download latest release
   http://github.com/thomasfrivold/luksus
   or just go to the shiny fancy page:
   http://thomasfrivold.github.io/luksus


##################
##### Notes ######
##################

DRAGONFLYBSD NOTES:
There are a few things to note about running this on DragonflyBSD...
#
NO EXT4, UFS IS USED 
EXT4 support is currently not available in a workable state in DFlyBSD;
The mkfs.ext4 tool shipped in e2fsprogs does not like the Dfly
loopback device, and I have not yet managed to get it to work.
Therefore the user will get a UFS filesystem instead.

TRUECRYPT NOTES:

Truecrypt defaults to using passphrase for volume security.
A keyfile can be added by using the commandline argument: usekey
This will add a key to the keychain in the volume, but TrueCrypt will
also ask for a password. 

TrueCrypt volume creation on loopback devices takes a lot of time,
regardless of size. Just hang in there, it will complete eventually.

Applies to both on Linux and DragonflyBSD
Truecrypt / tcplay is slow when it is creating encrypted
filecontainers on Linux. Once the volume has been created
speeds are nominal. This has at least been the case in my 
testing on Virtualbox instances of various Linux distributions.


Comments on feedback:
* There are factions who have voiced that they think this project
unnecessary. I tell these people they can either fork my project, 
submit code via github or choose to walk away.

In fact this reminds me of when I built an outdoor balcony for
family house. Every carpenter in the neighbourhood came by our house, that
sunny weekend, and chimed in on building techniques, pitfalls and
whatnot. Without exception they all condemmed my project
saying it would fail and that with my building technique the balcony
would only last for one season. 10 years on, the balcony is still
there, the ice and tundra hasn't twisted the wood foundation, and
it helped raise the value of the appartment by 10%.
I see the same kind of sentiments from uber-coders about my project here,
and really I don't care since they are not giving constructive
feedback such as real suggestions with code suggestions.

* Whiptail seems to have unstable commandline options, and it seems
to break randomly. I am considering eliminating whiptail support
after all the pain involved in seeing where it isn't transparently compatible with
dialog.


########################################################
################### TODO ###############################
########################################################

[wishlist / target for next version]
v2.0
Use steganography on keys - eg. allowing a key to inserted into an image
second idea is to put a key into the metadata of a media-file such as the ID3V2 section of an mp3 file, FLAC og meta-data of a JPEG or PNG
Different background colours

v1.7.0
Add:
+NetBSD Support
+OpenBSD Support
OpenSSL directory support
GNUPG PGP key support

Code improvements:
Complete OpenSSL
Complete implementing the NetBSD specific logic missing
Write a fool proof dependency check routine
Complete implementing OpenBSD bioctl code
Clear out the temp files properly, every time
Let CANCEL actually work everywhere
Consider running CHECKS after menu is done
Implement robustness advice from bash-guides
Improve menus from examples here: - http://bash.cyberciti.biz/guide/A_menu_box
 Attempt to follow the Google shell script manual of style:
 Consider which variables need to be set to readonly
 Set variables local
 Make all variable names lowercase
 Make all function names lowercase
Improve conditional statements, get rid of redundant echo "" lines

* Some engines do not support keyfiles, and yet I let the user
specify keyfile usage with these engines. This needs to be fixed,
just so that the user experience is smoother. Could be part of the
autodetector.

Project government, community feedback:
Write a proper Markdown webpage on the GitHub readme file

Engines todo:
Create an autodetector on OS and present available engines based on OS
Add OpenBSD , bioctl support
Add ecryptfs container support (maybe, if feasible)

wishlist / for future releases:
Consider changing wizard out with form based menu
as seen here http://bash.cyberciti.biz/guide/The_form_dialog_for_input

# User interaction things
Improve LUKSUS output in Dialog window:
remove keyfile information if the user is not using a keyfile.

# bad idea, this will probably not happen
Consider using GNOME GDIALOG OR ZENITY OR YAD. 
This would make the script graphical. Consider how to
ask the user about this. ** Must be tested thoroughly. **
[still considering, zenity and yad wasn't that good. Maybe this will
lead to bloat]

Add a discussion to this readme file - Key vault:
[this shouldn't become a feature, but rather part of the
documentation: Keyfile management] 
Add strongbox/keyvault option+Debate whether to call it strongbox or keyvault
(this might not be necessary since the user can simply use LUKSUS to
create a stronbox, this should rather become a part of the README
file. And it should become a suggestion)


########################################################
###################  CHANGELOG  ########################
########################################################

v1.6
+Added OpenSSL support
LUKSUS can now encrypt files using OpenSSL

v1.5
+ Added GNUPGP support with a filemanager to
pick files. 07.05.2014

v1.4 07.05.2014 01:52 GMT+1
+Finally got around to removing silly regressions on FreeBSD.
These bugs slowed down development of the rest of LUKSUS by
half a year or maybe more. Well. Solved now!
+Fully tested on FreeBSD. All features ok. All bugs fragged.

v1.3.3
+Introduced nice dependency checks.

v1.3.2
Code improvements

v1.3.1  21:30 27.10.2013
Whiptail options are unstable and troublesome. Support removed until later
notice, relying on dialog.

v1.3 00:45 25.10.2013
+The menu system is now complete.
+Code improvements

V1.2.9 14:50 23.10.2013
Great strides has been taken to improve the code.
Added a debug mode, can be enabled in the VARIABLES section. Devs only.

v1.2.8 19:25 17.10.2013
+Very nice looking menu created
Got some ideas from here: a complete menusystem I borrowed some ideas from:
http://www.bashguru.com/2011/01/menu-driven-shell-script-using-dialog.html

v1.2.7
+Preliminary menu system works
It is not pretty enough yet, but the idea is that from now on, the
user will not have to use commandline options. Dialog og whiptail is
required.
+Added whiptail support, which will not require dialog on Debian based
systems. Thanks Stackexchange! 
http://unix.stackexchange.com/questions/64627/whiptail-or-dialog
+Command line arguments are now optional, a dialog/whiptail will ask the
user for options.

v1.2.5
Preliminary menu system is almost a reality

v1.2.3
+Attempts were made to add crude NetBSD support


v1.2.2
Create a label to newly created filesystem, based on $name (Linux only)
Better usability of the information file of each volume.
Improvements to output 

v1.2.1
Fixed a tiny mistake.

v1.2
Fixes some regressions

v1.1
Adds FreeBSD support

v1.0
LUKSUS is stable and mature enough to be called 1.0
Tested on Linux and DragonFlyBSD


v1.0RC9 03.08.2013
The testing phase of LUKSUS has really forced a lot of 
improvements all over. The code is now completely modular, and
adding further encryption engines and operating systems should
be a walk in the park.
Now executes flawlessly in all operating modes on Linux and DragonFlyBSD

v1.0RC8 02.08.2013
+ added nodialog option and FreeBSD support
+ Dialog use is not enforced anymore. If package is not installed,
+  then the script will skip fancy dialog use. Dialog is not shipped
+  with all distros by default. Less headache for the user.


v1.0RC7 30.07.2013
+Cleanup

v1.0RC5 29.07.2013 12:30

+LUKSUS now defaults to passphrase. Using a keyfile is 
optional. User feedback suggested that many users preferred
to use passphrase instead of keys. Therefore the default
has been set to passphrase, with using keyfiles being optional.
+The dawn of modularization of the encryption engine code.
I am hoping to be able to add support for FreeBSDs GBDE and GELI,
NetBSD's CGD and OpenBSDs BIOCTL. This would bump the number of
supported platforms to 5.

v1.0RC4 22.07.2013 15:09
+Removed some extra integrity checks. They were redundant and broke
Truecrypt support
Feature freeze, and all that is required now is more testing.
Fixed some regressions. Testing is a good idea.

v1.0RC3 22.07.2013 12:00
+Better dialog - yesno now works
I like where this is going

v1.0RC2 18.07.2013 19:00

+Improved logging and reporting further
+Cleaner OS Detection

v0.99
Truecrypt command line option added
Usage cleanup
Readme testing

v0.95 06.03.2013 15:13
+Truecrypt support

v0.8.91 05.03.2013 20:00
Small bugfixes

v0.8.9 05.03.2013 13:28
+DragonFlyBSD support is now fully supported.
Cryptsetup / dm-luks spends a lot of time with its operation, 
10-15 minutes, but apart from that, LUKSUS runs on DragonFlyBSD.
Functions need more attention and cleanup, but everything is working
quite well now.


v0.8.5 26.02.2013 12:00
Cleanup before public release on Freecode.com!
Hello World

v0.8.4 26.02.2013 10:00
Added a routine to check the screensize, and display
a logo according to which screensize the user has.
Cleaned up a little bit here and there

v0.8.3 25.02.2013 20:00
Tweaks 

v0.8.2 25.02.2013 15:00
Added a welcome sequence
Added a logo! (yay)

v0.8.1 25.02.2013 14:30
Added missing apostrophe

v0.8 24.02.2013 10:15
+ Improved code quality, implemented simple modularization.



v0.7 02.01.2013 13:20
+ Added support for loopback devices 
  creating an encrypted container is now possible with LUKSUS
+ Began work on implementing functions throughout
+ Added some conditional checks with regex

v0.6 02.01.2013 01:35
+ improved documentation (README file)
+ Added some nice sanity checks
+ Further cleaned up the code
+ Added a definite CTRL+C to cancel now
+ Added dependency checks

v0.5 25.04.2012 12:30
+ initial public release
  live on github here: https://github.com/thomasfrivold/luksus
  (yay)
+ massive cleanup
+ added a conditional check to verify that user is root
+ added a conditional check in the middle of the procedure to
  verify that a LUKS container has been created on the device
  good for integrity 
+ added a routine to hackup the luks header with a conditional
  check as suggested by the luks FAQ
  here: http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#6._Backup_and_Data_Recovery
+ fixed mounting procedure
  changed name of the script from cryptcreate to luksus
  the luksus name is more a pun than a functional name
  luksus means luxury in Norwegian and coincidentally it includes the main technology
  used to encrypt hardrives in Linux since the 2.6 kernels - Linux Unified Key Setup
  on a celebratory note, the script can now be considered stable. Even though
  it lacks some niceties such as a fully fledged ncurses dialog menu system
  which is aimed at version v1.0
  - Thomas Frivold 

v0.4
+ cleaned up script
+ added required runtime arguments

v0.3
+ added command line input

v0.2
+ cosmetic fixes
+ did some nice thinking about dialog

v0.1 16.04.2012 GMT+1 1320
+ initial release


###############################################
Developer documentation (notes to self mainly)
###############################################

Q: How do I add another encryption engine?
A: After having made the script more or less modular, this is the
steps necessary to add another engine to LUKSUS:

ADD OS UNAME TO OSTEST()
Add loopbackdevice to LOOPBACKTEST()
Write HOUSEKEEPING() function for the new OS if necessary
Create engine() enginekeyfile() and engineopen() functions
put these new engine* functions into the main LUKSUS file
TEST TEST TEST! It is easy to break things, so it is very important to
test a lot.

Q: What are the release preparations for LUKSUS?
A: Release preparation stuff to do:
*** Complete the extensive LUKSUS test procedure ***

Critical test:
Must pass all testing, not a single mistake in regards to user experience:
* Create volume on a physical drive (Virtualbox is fine) using keyfile
with every supported encryption engine.
* Create volume on a physical drive (Virtualbox is fine) using
passphrase with every supported encryption engine.
Create volume on a virtual file container (if supported by os) using
keyfile with every supported encryption engine.
Create volume on a virtual file container (if supported by os) using
passphrase with every supported encryption engine.

Do this for all supported systems, and make a note in Changelog about testing after
each OS has passed test.

+Extensive testing on supported platforms
++Tested and verified on all in testing spreadsheet: 
Linux> Debian, Ubuntu, Mint, Gentoo, Arch, Fedora,
FreeBSD> FreeBSD, PCBSD
DragonFlyBSD> DragonflyBSD. 
NetBSD
OpenBSD: OpenBSD, BitRig
Add a pager which will let the user read the README
from within the program


On the following systems - Test in virtualbox:
6 different Linux distributions: Debian, CentOS, Arch, Ubuntu, Fedora, Gentoo.
FreeBSD distros: FreeBSD, PCBSD
DragonFlyBSD
NetBSD

Frag any typos and silly formulations.
Frag any error messages.

Release it into the wild:
Bump version number in LUKSUS.variables
Update README Changelog and TODO
Push a new tag to Github
Update jekyll homepage at thomasfrivold.github.io/luksus
Post to Freshmeat
Consider posting elsewhere, if release is awesome enough.



### LEGACY README INFORMATION FOR THOSE NOSTALGIC PEOPLE OUT THERE ###

Legacy documentation for those who really wish to use command line
options (not necessary anymore):

The usage of LUKSUS can take two different forms, 
mainly whether you are using LUKSUS on a physical device or a
virtual file. These two requires somewhat different commandline
arguments. Volumename simply means nickname for the encrypted
drive/media. Optional parameters are: 
truecrypt - which enables truecrypt instead of using LUKS (Linux and
DragonFlyBSD only)
usekey - which uses a keyfile instead of a passphrase, which will be
placed in /keys (LUKS only, works on truecrypt as well, but it will
ask for a passphrase anyhow so this will add a keyfile to the volume)

EXAMPLES: 
ENCRYPT PHYSICAL MEDIA: Using password
./LUKSUS /dev/sdb1 rambo1
 
ENCRYPT PHYSICAL MEDIA: Using keyfile
./LUKSUS /dev/sdb1 rambo1 usekey

CREATING AN ENCRYPTED FILECONTAINER (LUKS on Linux and DragonFlyBSD)
./LUKSUS /dev/loop0 ENCRYPTEDVOLUME /encryptedvolume.encrypted 300M 
./LUKSUS /dev/vn0 ENCRYPTEDVOLUME /encryptedvolume.encrypted 300M
./LUKSUS /dev/md0 ENCRYPTEDVOLUME /encryptedvolume.encrypted 300M


To enable the use of TrueCrypt instead of LUKS append the option: truecrypt
./LUKSUS /dev/sdc1 library truecrypt
./LUKSUS /dev/loop0 ENCRYPTEDVOLUME /encryptedvolume.encrypted 300M truecrypt

This last example is a corner case. This would create an encrypted
filecontainer using truecrypt with a passphrase as well as with a keyfile.
That keyfile would then work as a backdoor or an extra way into the archive, in case the password gets lost.
./LUKSUS /dev/loop0 ENCRYPTEDVOLUME /encryptedvolume.encrypted 300M truecrypt usekey


As of version 1.0, LUKSUS defaults to passphrase
for securing the volume. Using a keyfile is optional
and can be activated by using the commandline option: usekey
as mentioned earlier.

optional commandline arguments are: usekey nodialog
usekey - will enable the use of a keyfile instead of a passphrase
nodialog - will disable dialog prompts. Some people wants this.


ENCRYPTED FILECONTAINER
It is possible to create an encrypted file container
The usage then changes a little as the script then needs to
know which loopbackdevice you wish to use, where the encrypted
filecontainer should be located, and how large it should be.
Please note that the size must have M for megabytes or G for
gigabyte appended to the size.

The following will use loop0, and place the encrypted container in
/usr and will have 1000MiB as space.

./LUKSUS /dev/loop0 mysecretlibrary /usr/thelibrary.encrypted 1000M

For creating an encrypted filecontainer on DragonFlyBSD
./LUKSUS /dev/vn0 mysecretlibrary /usr/thelibrary.encrypted 1000M

###################################################
#### PRELIMINARY WORK ON VARIOUS FEATURES #########
#### SIMPLY KEPT HERE... TO KEEP THINGS SIMPLE ####
###################################################

*** PRELIMINARY WORK ON GPG SUPPORT ****
gpg -o myfile.gpg --cipher-algo AES256 --symmetric myfile
will require a filemanager

*** PRELIMINARY WORK ON THE NETBSD IMPLEMENTATION BELOW ***
*** KEPT HERE TO KEEP EVERYTHING IN ONE PLACE ***
Improve this script to make it working (NetBSD cgdconfig)
# The below lines almost make cgdconfig work... still have to work it out
#!/usr/pkg/bin/bash -x
#### The netbsd CGD drive encryption method is really arcane.

# create cgd partition
disklabel -i sd1
# scrub partition with random data
cgdconfig -s cgd0 /dev/sd1a aes-cbc 128 < /dev/urandom
# scrub partition with zero ... however it will be converted into random
# data using aes-cbc with a random key and cbc mode for XORing with previous
# sectors.
dd if=/dev/zero of=/dev/rcgd0a bs=32k
# destroying the random key
cgdconfig -u cgd0
# build the cgd config file
# skip the -V if you want data to be destroyed at first attempt of access with wrong key. For the truly paranoid.
cgdconfig -g -V disklabel -o /etc/cgd/sd1a aes-cbc 256
# specify the password
cgdconfig -V re-enter cgd0 /dev/sd1a
# create a disklabel (I don't really understand why we do this at this particular point in the process)
disklabel -I -i /dev/cgd0
# create filesystem
newfs /dev/rcgd0a
# configure cgdconfig - is this necessary???
echo "cgd0 /dev/sd1a" >> /etc/cgd/cgd.conf
---

some pragmatic snippets of code, that probably will
be implemented for dialog handling:
#!/bin/bash
device=$(dialog --inputbox "Enter the device to create volume on. E.g. /dev/sdd1 or /dev/loop0" 10 30 3>&1 1>&2 2>&3)
name=$(dialog --inputbox "Enter the volume name (nickname of the volume). E.g. Mystuff. Note no special characters or spaces" 10 30 3>&1 1>&2 2>&3)
luksfile=$(dialog --inputbox "Full path of encrypted volume" 10 30 3>&1 1>&2 2>&3)
luksfilesize=$(dialog --inputbox "What is the desired size of the container. E.g. 100M or 25G" 10 30 3>&1 1>&2 2>&3)
echo $device
echo $name
echo $luksfile
echo $luksfilesize

some code for improvement of the menu system

#!/usr/bin/env bash
t(){ type "$1"&>/dev/null;}
function Menu.Show {
   local DIA DIA_ESC; while :; do
      t whiptail && DIA=whiptail && break
      t dialog && DIA=dialog && DIA_ESC=-- && break
      exec date +s"No dialog program found"
   done; declare -A o="$1"; shift
   $DIA --backtitle "${o[backtitle]}" --title "${o[title]}" \
      --menu "${o[text]}" 0 0 0 $DIA_ESC "$@"; }



Menu.Show '([backtitle]="Backtitle"
            [title]="Title"
            [question]="Please choose encryption ENGINE:")'          \
                                                   \
            "LUKS"  "LINUX NATIVE"                \
            "TRUECRYPT"  "TRUECRYPT (TCPLAY)"                \
            "GELI"  "FREEBSD NATIVE"                \
            "CGD"  "NETBSD NATIVE"    

source: http://unix.stackexchange.com/questions/64627/whiptail-or-dialog

whiptail implementation
foobar=$(whiptail --inputbox "Enter some text" 10 30 3>&1 1>&2 2>&3)
http://stackoverflow.com/questions/1970180/whiptail-how-to-redirect-output-to-environment-variable

whiptail tutorial

whiptail --menu "Choose encryption engine" 10 40 4 \
               LUKS "" off  \
               TRUECRYPT "Popular Ubuntu"   on   \
               GELI "Hackish Fedora"   off  \
               CGD "Stable Centos"    off  \
               PGP "Rising Star Mint"   off  2>ENCRYPTION

source: http://www.techrepublic.com/blog/linux-and-open-source/how-to-use-whiptail-to-write-interactive-shell-scripts/