OpenSSL is a library. It should support whatever the standard supports and
whatever users and/or authors of the lib desire to be in the lib. That may
include broken or null-ciphers. But the user should have to take positive
action to get at the broken ciphers. I believe by default, OpenSSL should
ship with the weak ciphers disabled. And there should be a clear warning:
"Not secure, don't fool yourself, do not use, etc]".
Offering ROT-13 in a library you one maintains is one thing. Making broken
crypto an Internet security standard is another matter entirely. Doing so
is bad engineering, bad for the Internet as a whole, and ultimately worse
for security purposes than no crypto at all. (Reader: see other posts on
this topic if the last statement doesn't make sense to you).
--Lucky
On Fri, 25 Jun 1999, Jeffrey I. Schiller wrote:
>
> Ben Laurie wrote:
>
> > OpenSSL has them disabled by default. But I am torn on this question:
> > these new ciphersuites give greater strength than existing ones when
> > interopping with export stuff. Is it sensible to refuse to add stronger
> > ciphersuites? If it isn't, because they are crap, should we (the OpenSSL
> > team) disable _all_ export ciphersuites?
>
> Speaking as a user of OpenSSL... Today I can accept RC4-40 connection on my
> servers from export browsers.
-- Lucky Green <[EMAIL PROTECTED]> PGP v5 encrypted email preferred.
