NYCPHP Meetup

[Jim Hendricks]

> Hehe, tho' it is getting to be time for lunch I'm not referring to the
> condiment.
>
>  From php.net, in reference to crypt:
> string crypt ( string str [, string salt])
> http://us3.php.net/manual/en/function.crypt.php
>
> My impression is that the salt is the string that you can provide to
> enable the encryption.  In the case of crypt, if you don't provide one,
> one will be provided for you.
Ah, so that is SALT.  I don't use DES nor crypt since I use my own
implementation of RC4.

> Perhaps this isn't analogous to your RC4 method, as you are prepending
> the random string to the end of the the password and then encrypting...
RC4 is a simple stream permutation/substitution cipher. There are only 2
things you need for encryption, the plaintext/data to encrypt and a key. In
my
case, the plaintext is a few random characters + the password + a random
generated string to use as a key for encrypting other data.  If I don't need
the personal encryption then my plaintext is a few random characters + the
password.  The key I use for encryption is the users password.  Validation
is simply decrypting the stored ciphertext using the users plaintext
password.
If I know I used 3 random characters then I start reading the decrypted data
starting at position 3 and compare to the plaintext password, if it matches
character for character, I know the password is valid.  If the personal
encryption
is used, then anything after the password in the decrypted data is the key
for personal encryption, this is stored as a session variable so any pages
which need to use personal encryption has access to this additional key.

With all that said, and my initial impression of SALT in DES, then no,
SALT does not provide the same functionality as my random prepended
data. At least not in the same way.  SALT looks more like Key data since
crypt is using DES for HASH generation & DES is not that I am aware of
a HASH algo, but an encryption algo.  The difference in an encrypt and a
HASH is in the results.  Encryption is a two way process where the
ciphertext can be turned back into the plaintext with the proper inputs.  In
the case of RC4, you encrypt with plaintext and a key, you decrypt with
ciphertext and the same key you encrypted with.  A HASH function on the
other hand generates a mathematical identifier which cannot be turned back
into the original plaintext and is therefore oneway.  I personally like to
view
a hash as similar to a checksum.  The resulting HASH can be the same
as the resulting HASH for other data, so the HASH is not unique to the
HASH'ed data.  Depending on the HASH algo determines how likely it
is for another dataset to result in the same HASH.  It is because of this
potential for another set of data to generate the same HASH I personally
don't like to use HASH's for security.  I'm sure it's an irational fear on
my
part, but since RC4 is so easy to implement, I stick with that.