资源说明:LUKSUS
__ __ __ __ __ _____ __ __ _____ / / / / / / / //_/ / ___/ / / / / / ___/ / / / / / / / ,< \__ \ / / / / \__ \ / /___ / /_/ / / /| | ___/ / / /_/ / ___/ / /_____/ \____/ /_/ |_| /____/ \____/ /____/ # 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/
本源码包内暂不包含可直接显示的源代码文件,请下载源码包。