-------------------------------------------------------------------------------
Rules of Cryptography

First rule of cryptography and password storage is "Don't invent it yourself".

But if you must here is the absolute minimum you must do to have any semblance
of security:

Cardinal rules:

   1. Do not invent your own "clever" password storage scheme. I know, you're
      smart, and you grok this crypto stuff. But through this door lies
      madness.
   2. Never store a plain text password (which means you can never display or
      transmit it either.)
   3. Never transmit the stored representation of a password over
      an unsecured line (either plain text, encoded or hashed).
   4. Speed is your enemy.  The slower it is to verify a password, the better!
   5. Regularly reanalyze and improve your process as hardware and
      cryptanalysis improves.
   6. Cryptography and processing is only a very small part of the solution.
   7. Points of failure include: storage, clients, transmission, processing,
      users, legal warrants, intrusion, administrators, rubber hoses (torture).

Steps for Cryptography:

   1. Enforce some reasonable minimum password requirements.
   2. Change passwords frequently.
   3. Use the strongest hash you can get - SHA-256 was suggested here.
   4. Combine the password with a fixed salt (same for your whole database).
   5. Also combine the result of previous step with a unique salt (maybe the
      username, record id, a guid, a long random number, etc.) that is stored
      and attached to this record.
   6. Use a cryptographically secure hash, multiple times.  Run it enough to
      take at least a few seconds on a good machine.  Speed is your enemy and
      multiple iterations reduces the speed.

NOTE: The MD5 hash was designed for speed, which is bad.

Oh, and unless you are running SSL or some other line security then don't allow
your password to be transmitted in plain text. And if you are only comparing
the final hash from the client to your stored hash then don't allow that to be
transmitted in plain text either. You need to, then send a nonce (number used
once) to the client and have them hash that with their generated hash (using
steps above) and then they send you that one. On the server side you run the
same process and see if the two hashes match. Then dispose of them.  There are
a better ways, but that is the simplest one.

-------------------------------------------------------------------------------
Types of Encryption

There are essentially 5 types of encryption...

1/ File, Archive, Stream encryption (GPG file, and ZIP)

   Encrypt individual files, archive files, and character streams
   These generally go well together with compression.

   General Notes     See "file_encrypt.txt"
   Using OpenSSL     See "openssl.txt"
   Using Perl        See "perl_encrypt.hints"

2/ Disk or Block device encryption (TrueCrypt, VeraCrypt, and DM-Crypt)

   Encrypt the low level saved blocks of the storage device, the file system
   is then built on top of that encrupted storage.

   CryptoLoop   Using loopback devices (Old)  See "linux_crypoloop.txt"
   DMCrypt      linux device mapper         \
   CryptSetup   using "cryptsetup" command   >- See "linux_dmcrypt.txt"
   LUKS Crypto  Formalised Disk encryption  /
   JungleDisk   See "jungledisk.txt"
   TrueCrypt    See "truecrypt.txt"
   VeraCrypt    Successor to TrueCrypt

3/ Directory Level Encryption (EncFS, CryFS)

   All files in a sub-directory are encrypted with encrypted filenames.
   The encryption is built on top of an existing file system, using
   two mounts; a direct with encrypted files, and and unencrypted mount

   This form CAN generally be used on cloud file services like dropbox,
   or over NFS from a SAN.

   CryFS        Simular to EncFS, though slower (breaks up files and matedata)
   Gocryptfs    much like EncFS usng GCM (integrity checks)
   EncFS        See "encfs.hints" -- lots of client programs, some weakness
   eCryptfs     Original concept using NFS server to do the encryption.
   Cryptomator
   FuseFlt      (using  flt_cmd = gpg --encrypt)

4/ Public Key File Encryption (GPG, one key encrypts, one decrypts)

   Typically the keys are bi-directional, and one key is made public,
   allowing anyone to encrypt data, such that only you can decrypt.
   This is typically at the heart of encrypted communications.

   PGP & GPG   See "public_keys_gpg.txt"

5/ Stenography (hiding data, in other data)

   Storing extra data as part of some other innocuous file.
   The file should work as normal, ignoring the extra hidden data within.

   Though if the file is re-written or otherwise modified the hidden data can
   become lost.  A simple way is to just append the data to a file type that
   has a well defined 'end of data'.

   This isn't technically encryption, but the hidden data is usually password
   encrypted as well as hidden.

   Examples:
     * Low bits of an image, image quaility is lowered very slightly
     * HTML comment in a web page (easilly spotted in raw data)
     * In the free space of a hard disk that is never updated (read-only).

   See "file_hiding.hints"  and "passwd_obfuscation.txt"

-------------------------------------------------------------------------------
The Perfect Cryptography...

There is a perfect method of cryptography, that is unbreakable, even with
brute force attacks.   The one time pad.

Basically XOR with a purely random key that is the same length as the message
being encrypted.  Without the key, a brute force attack can never decrypt the
message, as they could generate anything at all, not just the original message.

However any given key should only be used once with any given message, and the
key is as long as the original message and also has to be sent via some means,
generally using some secondary channel.

For example. Take a well known book, and use it as the encryption key!
One famous one time pad is the King James Bible.

It is however important that the key is only be used once, and once only.
Repeated use will make the key vulnerable to discovery by comparing multiple
encrypted texts.

As key is as long or longer than the original message, it becomes unmanageable.
You need to store it and thus the key could be easily stolen or in the case of
public property (like a book), it becomes known as the key being used.

Also you would need to ensure that the key never changes while the message is
needed. If it does, the message can be no longer be deciphered.

This is why almost all cryptography uses some type of hashing function to
convert a cryptographic key of reasonable length, into a long sequence that is
combined with the message to encrypt/decrypt it.

-------------------------------------------------------------------------------
Preventing Brute Force Cracking.

That is just trying every key until the message become clear.

There certain things that can prevent the use of brute force in decrypting
messages.
  1/ Longer Cryptographic Keys   (that is pretty obvious)
  2/ The cryptographic process being known precisely.  (security by obscurity)
  3/ The 'clear-text' that is not itself 'clear' (two level encryption)

Security by Obscurity...

If the actual method of encryption/decryption is not known then no brute force
attack will ever generate clear-text.  But such security (though obscurity) is
generally NOT considered good, as eventually any such method does become known.
For example the code is examined.

Clear Text isn't Clear...

Brute force attacks requires the resulting decrypted text to be recognisable as
being decrypted.  For example the message become English Text, mostly ASCII, or
some other known file format, checksums succeed (message validation), or can be
successfully used for its intended purpose.  So if the clear-text of the
encryption is not actually clear, having no recognisable order to it, then it
is not going to be flagged as decrypted.

So if the 'clear-text' of the encryption is itself an encryption (without an
identifier, or a recognizable compression, or some other text randomization
method, then the brute force method can never know when it has succeeded!

However most encrypted files generally include a header that identifies the
file encryption being used.  As encrypting a file twice will generally not
work.   The first encryption of the data (before being encrypted again) has to
not store anything recognisable.  No Magic Value (format identification
string), or even basic information such as a reconsible Salt, or Hashing
Iteration Count.  Nothing that could make the result recognisable as anything
but purely random garbage.

This is where it fails.

As such the only real defence against pure brute force cracking is a longer
cryptographic key.  Not only that, as time goes on, and computers get faster
(and GPU's more parrellel), that key needs to get longer still.

-------------------------------------------------------------------------------
Secure Wiping of data

  shred       overwrites the data multiple times, before deletion (-u)
  overwrite   http://www.kyuzz.org/antirez/overwrite.html
  badblocks   writes "-c {n}" blocks using "-t random" data to a disk

For whole disks

  Darik's Boot and Nuke
    http://www.dban.org/

-------------------------------------------------------------------------------
pwc.pl   A 3 line perl password cracker

First reads the system passwords into a %u hash, using getpwent().
Then tries each word from a dictionary file (command line argument)
against them, using crypt().

Essentially a brute force dictionary attack against the system.

#!/bin/perl -- -pwcracker-in-3-lines-of-perl
$u{$p[1]}=$p[0] while(@p=getpwent);while(<>){chop;foreach $c (keys %u)
{printf "u=%s p=%s\n",$u{$c},$_ if(crypt($_,$c) eq $c);}}

-------------------------------------------------------------------------------
For random numbers see
  ../shell/random.txt

-------------------------------------------------------------------------------