8 years ago
Vincentv, I don't think implimenting and reading a USB based Token File as a superstrong passphrase would take hardly any resources beyond the USB flashdrive which are as inexpensive as 1-2 US Dollars.
Instead of reading the passphrase on the Linux system hard drive as a comparison to the user inputed passphrase, the re-coded portion simply reads the token file first 256 bits or whatever is the maximum passphrase length in data bits. Added programming would be minor in regards to adding the optional Read statement from a file instead of the user Passphrase Input statement.
The greatest weakness using modern encrypted Linux systems is in the users passphrases being far to weak. This optional suggestion entirely address's that as well as gives business's and office managers the ability to temporarily share a root passphrase via a removable USB token file then remove it without actually telling the employee or worker what that system passphrase is nor having to physically be there typing it in.
A Further Case for adding a Keyfile Option to Mint Linux Login as well as for the installation encryption option to supplement a moderately strong password or if the installer choses to entirely use a CD/DVD/USB Pendrive base Keyfile as the Login Passphrase.
On a system encrypted with ecryptfs, folder, home directory or disk ANYONE that succeeds in a Bruteforce Attack on the Linux Distro Passphrase Login can the proceed via the CLI terminal to easily break into your encrypted files:
Recovering Your Mount Passphrase
In the event that you did not write down your mount passphrase, you may be able to recover it by decrypting the file /home/username/.ecryptfs/wrapped-passphrase using your login passphrase.
Type the login passphrase to reveal the mount passphrase
If the login passphrase matches the passphrase used to encrypt the wrapped-passphrase file, your mount passphrase will be written to screen. Record and protect this data accordingly.
Without the option for a keyfile being read to suppliment the login passphrase, in many cases the user passphrase is weak to moderate in strength providing a point of probable attack.
Providing a Keyfile Option to suppliment the login passphrase would seriously deter a brute force attack AND Providing a 3x failed login passphrase attempts resulting in a 3 or 5 minute delay would also serve to deter any brute force attacks.
Reference on creating a quick,random 4096-bit keyfile. Rename the file to whatever you wish (.mp3,.zip,.tar) move it to a nest of external files on a Pendrive,CD or DVD and change the permissions to Read Only.
Create a keyfile via CLI:
sudo dd if=/dev/random of=/../mykeyfile bs=4096 count=1
Thank you for your comment dice and best wishes to you, your family and the readers during the Christmas Holidays.
Both Twofish and Serpent were Advanced Encryption Standard 1999 finalists.
Rijindael chosen to be AES was largely chosen for it's speed rather than being the strongest encryption algorithm. The strongest among the finalists was Serpent and Twofish with Rijindael coming in third but still strong enough in 1999 to be considered 'secure' however as noted above, AES designed to be a fully adopted standard for internet and computers in 1999 to be fast and not a heavy CPU loading burden. RC6 which is still widely used today and Mars were the other finalists.
In 2011, Linux Kernels and off the shelf CPU's contain AES algorithms and encryption accelerators making for a near seamless (time-wise) handling of encryption and decryption for the users.
When US Gov.hackers (hackers forced to work for US Gov.agencys or face long federal prison terms) began hijacking AES led bank money transfers, a very large number of corporations silently began switching away from AES encryption. I 'suspect' NSA was able to crack AES but that is simply a 'hunch'. During that time 2001-2010 I used a fire fox plugin to tell me what the banks and major IPS and corporate sites I was attacked to was using for their encryption standard. Many had suddenly shifted away from AES (Rijindael) especially the Hong Kong banks which seem to have a pulse on the rather dark undercurrent that happens behind the scenes.
Directly comparing Rijindael or Serpent, Serpent is hands down far more secure in its construction because it uses 32 rounds of encryption vs Rikindael's 14.
Advances with supercomputers have publicly stated they have defeated 10 rounds into encryption algorithms and although that is not a complete 'crack' or defeat of an encryption algorithm of 14+ rounds it is by no means what has been achieved privately. AES-128 Bit is 10 rounds, AES-196 is 12 rounds and AES-256 is 14 rounds. Perhaps now you realise why the 10 round 128 bit version is often exported to be send overseas.
A nice graphic comparison between AES (Rijndael) and Serpent encryption algorithim: http://www.scribd.com/doc/4522/Comparison-between-AESRijndael-and-Serpent
AES Finalist Votes:
RIJNDEAL 86 votes
SERPENT 59 votes
TWOFISH 31 votes
RC6 23 votes
MARS 13 votes
The Twofish team Safety factor is defined as: number of rounds of the full cipher divided by the largest number of rounds that has been broken. Hence, a broken cipher has the lowest safety factor 1. Serpent had the highest safety factor of the AES finalists: 3.56 (for ALL supported key sizes). Rijndael-256 had a safety factor of ONLY 1.56.
The general observations of the first three ciphers were as follows:-
Performs well across all considered platforms. Its key setup is
fast, and its memory requirements are low, so it also should perform
well in hardware and in memory-constrained environments. The straightforward design and the conservative choice of operations should facilitate its further analysis, and the operations should be relatively easy to defend against certain attacks on physical implementations. Even though parallel processing was not considered during the Round 1 selection process by the AES review team, Rijndael has the potential of benefiting from advances in computer processors that allow many instructions to be executed in parallel. Rijndael was submitted to the AES development effort by Joan Daemen and Vincent Rijmen.
Is ultra-conservative in its security margin: the designers chose to
use twice as many iterations as they believed secure against currently
known attacks. Consequently, Serpent's performance is relatively slow
compared to the other four finalists; however, in some settings this
should be mitigated by the efficiency of optimised implementations using
what the submitters call the ``bitslice'' mode, for which the algorithm
was specially designed. Serpent should fit well in hardware (with potential
tradeoffs of speed versus space) and in memory-constrained environments.
The straightforward design and the conservative choice of operations
should facilitate further analysis of this candidate, and the operations
should be easy to defend against certain attacks on physical implementations. Serpent was submitted to the AES development effort by Ross Anderson, Eli Biham, and Lars Knudsen.
Exhibits fast and versatile performance across most platforms; it also
should perform well both in hardware and in memory-constrained environments. It features variable substitution ``tables'' that depend on the secretkey. The submitters believe that such tables generally offer greater security than tables with fixed values. The possibility of pre-computing these tables to varying degrees helps Twofish to offer a wide variety of performance tradeoffs: depending on the setting, Twofish can be optimised for speed, key setup, memory, code size in software, or space in hardware.The highly respected Twofish team asserts that key-dependent S-boxes constitute a form of security margin against unknown attacks now and in the future. Twofish was submitted to the AES development effort by Bruce Schneier,John Kelsey, Doug Whiting, David Wagner, Chris Hall, and Niels Ferguson.
I also included the plea for the Mint Team to add the keyfile option (external device file) to supplement a often weak password or entirely be used as one. Such can and are stored on CDs,DVDs and USB pendrives often among a haystack of normal files. Such is a boon for Administrators and a nightmare for thieves.
Both GnuPG and PGP fully implements AES and Twofish also.
The most secure encryption employing the AES finalists is:
AES-Twofish-Serpent in a cascading encryption with the XTS method using the Whirlpool hash algorithm and strong passwords supplemented with keyfiles. Thugs or agencys attempting to defeat the cascaded encryption would likely assume the file is encrypted with AES but run into the cascading encryption of Twofish followed by Serpent and get nowhere.
The FBI and National Institute of Cryptology threw in the towel in attempting one full year to crack into a South American bankers computer that was encrypted with the above method. http://www.webcitation.org/query?url=g1.globo.com/English/noticia/2010/06/not-even-fbi-can-de-crypt-files-daniel-dantas.html
Nice idea although I would mention modern algorithms like AES etc.