[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I'm probably missing some c headers, but what ?
Orr Dunkelman writes:
> Oded, I strongly recommend on using other function the the given crypt
> function. In unix there are two crypt functions - one uses ENIGMA, the
> german rotor machine used in the second world war, the second uses a
> variant of Date Encryption Standard (DES).
There's a command, crypt(1) which implements an algorithm designed along
the lines of Enigma. This functionality is not available in a library
function, AFAIK.
> Enigma was broken in the 40's, and is very unsecure (UK and USA could have
> broken the enigma encrypted messages without computers... today it's more
> the trivial).
There remain still unbroken Enigma messages.
Enigma is vulnerable to known-plaintext attacks, and this is how most messages
were broken. (This is also the attack that CBW, the Crypt Breakers Workbench
implements.) There are published ciphertext-only attacks against it, but they
are practical only against long (i.e. longer than the ones in WWII) only.
Don't get me wrong though, because of the known-plaintext vulnerability and
the otherwise requirement for short messages, Enigma is not a good choice for
a cipher today.
> DES is considered to be a very weak encryption function. It uses 56 key
> bits (you give it up to 8 byutes - 64 bits), and therefore considered
> weak. Last time I've checked a DES mmachine broke DES in about 22 hours.
> Just to give you a ratio, 64 bits encryption is passe, it is considered on
> the edge of safty (each new key-bit, multiply the time needed to the
> breaking phase by 2).
Just so there's no mistake, this is simply a problem with DES key size that
makes it vulnerable to brute force searches using advanced hardware and high
parallelism. In fact, 3DES (which is roughly ``encrypt 3 times using DES'',
establishing a 168 bit key) is the currently recommended encryption method by
the IETF and banking standards.
Regardless, standard crypt(3) implements a modified algorithm, which changes
slightly depending on the password. One of the main reasons behind this
``salting'' of the hash was to defeat hardware attacks.
The problem with crypt() is general is not in the strength of the algorithm,
but the fact that users tend to choose weak passwords.