Advanced String Encryption
[1/3] from: etcha::gsat::net::au at: 4-Sep-2000 8:08
This is a multi-part message in MIME format.
------=_NextPart_000_000D_01C01647.49000100
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
All,
I call for the need to create a highly advanced string encryption/decription function
volunteers will be appreciated
aden.
------=_NextPart_000_000D_01C01647.49000100
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META content='"MSHTML 4.72.3612.1706"' name=GENERATOR>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#000000 size=2>All,</FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT> </DIV>
<DIV><FONT color=#000000 size=2>I call for the need to create a highly advanced
string encryption/decription function</FONT></DIV>
<DIV><FONT color=#000000 size=2>volunteers will be appreciated</FONT></DIV>
<DIV><FONT color=#000000 size=2></FONT> </DIV>
<DIV><FONT color=#000000 size=2>aden.</FONT></DIV></BODY></HTML>
------=_NextPart_000_000D_01C01647.49000100--
[2/3] from: joel:neely:fedex at: 5-Sep-2000 5:23
If by "create a ... function" you mean that you'd like REBOL
Technologies to add a well-known, well-tested, high-security
algorithm (e.g., blowfish, twofish, or whatever wins the AES
competition sponsored by NIST) to REBOL as a primitive (for
performance reasons) then I'm happy to second the request.
This would be a valuable feature, and could be a critical
part of the support for no-human-readable-source distribution
of REBOL programs (also a valuable feature, IMHO).
If by "create a ... function" you mean that you'd like for a
group of volunteers to try to invent an en/de-cryption scheme
and implement it in REBOL, I'll be strongly of the opposite
persuasion:
1) REBOL should support relevant industry standards wherever
feasible. As NIST is the appropriate agency, I suggest
that their guidelines be followed. Please see
http://csrc.nist.gov/encryption/aes/
for more information on the Advanced Encryption Standard
Development Effort.
2) Cryptography is SEVERELY non-trivial. The only way that
I would begin to trust a cryptographic algorithm (including
some designs which I've created for fun) is for it to be a
published design which has been kicked around for YEARS in the
crypto community. Open source (including intensive expert peer
review) is the only way to achieve reliable cryptographic
security. Please see
http://www.counterpane.com/
and
http://www.wired.com/news/technology/0,1282,38240-2,00.html
for more information on this.
3) Strong crypto is usually computationally intensive. While
I strongly advocate reserving performance optimization for
those critical parts of a system where there's really a need
for it (development/testing/maintenance time are usually much
more expensive than run time for the majority portion of the
majority of computer programs), an en/de-cryption function is
one such hot spot, IMHO.
4) If the whole point of crypto is security, then en/de-cryption
functions should be embedded into the language in a way that
minimizes the possibilities for a running piece of code to change
or replace them (or otherwise interfere with their function). We
all know that user-defined and official mezzanine functions are
vulnerable to modification (intentional or otherwise).
Please let me be clear that I am NOT trying to discourage or look
askance at any efforts toward experimentation or research into
cryptography, nor am I suggesting that REBOL is a bad choice for
such efforts.
But I AM saying that amateur/experimental/research efforts by the
REBOL community should not be the basis for "official" (in any
sense of the word) support for crypto in the REBOL language.
-jn-
[3/3] from: ptretter:charter at: 5-Sep-2000 11:47
Great information. I have the desire as many ecommerce folks also do.
Would be nice to see an ftp server/client that uses this encryption.