Ncrypt - NMRC file encryptor/decryptor/wiper
         Simple Nomad <thegnome@nmrc.org>
         Based off of code from Joh Johannsen <jojo@farm9.com>, Gary 
         Rancier <mephis5@softhome.net>, and Doug Whiting.


Quick Start
-----------

Step one - untar and gunzip:

$ tar xzf ncrypt-0.5.5.tgz

Step two - compile:

$ cd ncrypt-0.5.5
$ make

Step three - install (if you are root):

# make install

Otherwise simply copy the ncrypt file to a local bin directory in your 
path, such as $HOME/bin.


Features
--------

 - Open-source freeware.

 - Should compile on any platform that supports standard C libraries (no 
dependencies upon crypto libraries).

 - Use Rijndael, Serpent, or Twofish as the crypto algorithm. Rijndael is 
the AES selected candidate, Serpent came in second, and Twofish third. For 
details on AES and the selection process, check out 
http://csrc.nist.gov/encryption/aes/ for more information.

 - The plaintext password is converted to a SHA-1 hash and immediately 
wiped from memory securely.

 - Once the SHA-1 hash is used to make a key for encryption, the SHA-1 
hash is wiped from memory securely.

 - If running as root, will lock process memory to prevent paging to disk,
as the password or SHA-1 hash could be written to swap.

 - Optionally during encryption, the original unencrypted file can be 
erased with the drive space it occupied being overwritten thirty-five times 
using techniques outlined in Peter Gutmann's 1996 paper entitled "Secure 
Deletion of Data from Magnetic and Solid-State Memory", available from
http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html. A "wipe-only" 
option is also available that is indepedent of the encryption process, for 
those times when you need to get rid of a file permanently without keeping 
an encrypted copy.


Why I Did This
--------------

The reason this software was done was simply because of necessity. I had a 
series of needs, and I could not find the software I needed. I needed 
something that did not require extra libraries and could be compiled 
easily on most systems, had multiple encryption algorithms, had security 
and privacy in mind from the ground up, and had the ability to securely 
wipe files.

The Advanced Encryption System (AES) selection process looks promising 
(details are at http://csrc.nist.gov/encryption/aes/), mainly because of 
the peer review. It wasn't just a regular review by the government -- it 
involved some of the world's best crpytographers outside of the NSA. Since 
the selection process was close, and since you can bet that the top 3 
entries were really good, I included those top three algorithms -- 
Rijndael, Serpent, and Twofish.

I wanted to include the ability to completely wipe the original file after 
encryption. What good is it if you encrypt a file, when the plaintext 
version can be recovered with a minimal amount of forensics effort? 
Multiple passes over the file's space on the hard drive with zeroes and 
random data was a must.

No such program existed, so I did what many of us do -- I went out and 
found source code that was close, and starting hacking together something 
that was usable.


Target User
-----------

Here is a list of what I perceive to be as the typical users of Ncrypt:

Non-root users - If you have a shell account on someone else's system, 
like a shell server at an ISP, and you want to encrypt files to protect 
your privacy, Ncrypt was made for you. Odds are you won't be able to talk 
the sys admin into installing some cool crypto library (or updating an 
existing one), so you need something that will compile with basic C 
libraries. You need something you can install yourself (say in $HOME/bin), 
and you want to make sure the sys admin can't resurrect deleted plaintext 
files to read your private documents. Ncrypt does that.

Human rights worker - You need a simple and easy method to encrypt and 
decrypt files, and prevent a hostile government who might seize your 
computer from recovering your files -- even if they sneak into your hotel 
room while you are gone, and try to do it without your knowledge. You need 
a way to prevent the evil oppressors from recovering the plaintext 
versions. Ncrypt will do that.

Pen testers - Need a quick method to encrypt and decrypt files during a 
penetration test, especially if you are wanting to move such things as 
shadow password files and port scan results from the target network to a 
different system? If you got in through a hole and are collecting data, 
you don't want to leave that data sitting around in plaintext for a real 
intruder or disgruntled employee to find. You may not be able to install 
that crypto library on the production system you've compromised, so Ncrypt 
will work just fine.

Black hats - There is nothing more irritating than busting root on one 
system, hopping from system to system, and some sys admin finds your 
plaintext hacker tools and data. You could lose root on all those boxes! 
Having a handy utility that can compile without crypto libraries, and that 
can safely wipe plaintext files would be a great addition to any decent 
rootkit. Ncrypt will work for you.


Reporting Bugs
--------------

If you find a bug with the software, please let me know. I tried to ensure 
that the software would not be a security risk itself, and I've tried to 
get it to run as clean as possible. If for some reason the program 
segfaults, the core file could contain plaintext data, so make sure you 
thoroughly clean up after a segfault. Report bugs to thegnome@nmrc.org 
along with the conditions that caused the problem. If you patch the bug, 
send me a diff and I'll include it with credit (assuming the patch is 
approved, can't have a patch introducing a security risk!).


Potential Risks Associated with Ncrypt
--------------------------------------

In spite of the fact I've really tried to ensure the code is safe, there 
are a few scenarios I have considered as potential risk areas. I will 
outline those:

 - Signals and memory diddling. It is possible that if you are a non-root 
user on a system, root could send a signal or overwrite portions of memory 
causing ncrypt to core during Ncrypt's runtime. This could cause a 
segfault, and root could cp or mv the core file to a protected directory 
before you could securely wipe it, recovering part or all of the plaintext 
file. This type of attack could be automated. NOTE: I may attempt to code 
around this, but it will take some investigation, and me reading up on 
signal handling. If ulimit is used to prevent coring, this helps, but a
clever attacker running as root could still get around this.

 - System call tracing. If you are non-root, root could decide to ptrace
the ncrypt process and recover the password or SHA-1 hash. If you can
setgid to a non-privileged group (which may not be possible if you don't
have root) this will help.

 - Paging memory to disk. Normally for a security-related piece of code
one would use mlock or mlockall to prevent paging memory to disk. However
this is a privileged operation, and cannot be done if ncrypt is running as
non-root. Therefore it is possible that passwords or hashes could be written
to the swap and recovered by the system owner.

 - "Bad" system libraries. It is possible that some of the standard
libraries on a system may be "tainted", and designed to intercept key
read and write operations. The truly paranoid and untrusting may want to
always compile ncrypt statically on a known safe system, and copy the
binary to the untrusted host before running.

 - Kernel intercepts of system calls. There is the possibility that a 
kernel modification or module could be loaded that sees Ncrypt opening 
file handles, and then simply makes copies of all read operations to a 
separate file. Granted this could be tricky when wiping during encryption, 
but not impossible to code up. This could result in disclosure of your 
plaintext file.

 - Coding problem. It is possible that a buffer overflow, underflow, or 
some other method for introducing a security problem could be found in 
Ncrypt. Ncrypt was examined fairly extensively, but it is still possible 
that a problem might be found.

 - Crypto problem. There could be a problem in the coding of one or all of 
the algorithms used in Ncrypt that is currently undiscovered, that when 
exploited could result in cracking the encryption or key recovery. While 
some of the best crypto people in the world looked at these 
implementations during the AES selection process, some could still exist.

 - Plaintext recovery. In spite of the fact that Peter Gutmann's excellent
paper illustrates both recovery methods and methods for thwarting recovery
of deleted files in a seemingly logical manner, it still seems possible that
Mr. Gutmann's techniques are either incorrect or outdated in the face of
modern forsenic techniques. A possible attack vector exists where the original
plaintext file can be restored despite being overwritten 35 times using a
variety of bit patterns.

Simple Nomad
$Id: README,v 1.1.1.1 2003/02/15 02:50:30 s-nomad Exp $
