>>Care to suggest a few? I've seen several, but I'm not sure how to evaluate
them.
The trick is, there's no way you or I can adequately evaluate an encryption
algorithm for anything but speed. Therefore, you need to choose algorithms
that have been tested by cryptanalysis experts (which is why public
algorithms are so important).
All information below has been at least partially obtained from "Applied
Cryptography" by Bruce Schneier. The book includes C source-code for several
algorithms, including Blowfish, DES and IDEA. Highly reccommended if you
have any interest in cryptography.
For Hashes:
MD5 is still the standard almost everyone uses, though SHA and RIPE-MD are
probably more secure.
For Symmetric-Key Block Ciphers:
I like using Blowfish, it's public domain, and quite fast on 32-bit
processors. It has been used in a few commercial products.
The TwoFish algorithm is showing a lot of promise in the competition for
replacement of DES as the US Government standard. Other than that, I don't
know much about it.
IDEA is also a strong public cipher, it just never seemed to gain much
popularity. I'd be very comfortable using it.
Three-round DES is still fine for most uses, and has the advantage of being
available in public libraries. Single-round DES should not be used for
anything more valuable than your favorite cookie recipe.
For Symmetric-Key Stream Ciphers:
Stream ciphers are notably less secure than block ciphers, and are
generally only recommended for things like real-time streaming of data where
encrypting a "block" at a time is not practical (IE: hardware
implementations of "scramblers" for radio, etc...).
RC4 is commonly used, though it is not truly public, and use of it might
get you into conflict with RSA Data Security.
All the other stream ciphers I've seen are described as highly insecure.
Remember that these algorithms are not designed for "stored" information
where an attacker would have time to break it.
Assymetric-Key Ciphers, AKA Public-Key:
RSA and DSA are the current heavyweights, though elliptic curve algorithms
show a lot of promise. However, these are quite complex, and you'd best have
a thorough understanding of cryptography if you are going to write your own
implementation. Using PGP or GPG is probably the most practical way of using
public-key cryptography.
Michael J. Sheldon
Internet Applications Developer
Phone: 480.699.1084
http://www.desertraven.com/
PGP Key Available on Request
-----Original Message-----
From: Greg Saunders [mailto:[EMAIL PROTECTED]]
Sent: Saturday, May 20, 2000 18:38
To: [EMAIL PROTECTED]
Subject: RE: decrypt form variable...
At 11:52 AM 5/17/00 -0700, Mike Sheldon wrote:
>From looking at it, it's definitely different.
>
>However, it's also very definitely a stream-type cipher, not DES. This one
>produces exactly 2n bytes ciphertext for every byte plaintext input. I
don't
>think I'd trust this one to casual cryptanalysis either.
>
>Using this one may be more convenient, but will not be supported by
Allaire,
>and may be changed/removed at any time. The "secret" for working with
output
>from cfencrypt() is to base64 encode the results.
>
>All of this REALLY bugs the daylights out of me. There are free,
>cryptographically strong algorithms out there that have been tested and
>considered secure. There's no excuse for not using them.
Care to suggest a few? I've seen several, but I'm not sure how to evaluate
them.
Thanks,
Gregory M. Saunders, Ph.D.
Senior Design Architect
Cognitive Arts Corporation (http://www.cognitivearts.com)
120 S. Riverside Plaza, Suite 1520
Chicago, IL 60606
----------------------------------------------------------------------------
--
Archives: http://www.eGroups.com/list/cf-talk
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
Archives: http://www.eGroups.com/list/cf-talk
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
