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.