> The point is that in Netscape, it is very hard to tell if a given link
> is 40 bit or 128 bit. Sure, with enough poking around looking at page
> info you could probably figure it out. Or maybe someone knows if the
> little padlock means something like the little key used to. But
Steve Mynott wrote:
>
> There used to be two keys I believe a little (weak) key and a larger (strong)
> key. In the (patched to domestic US strength) version of Netscape I use
> (Linux 4.07) the padlock is always the same size. It may be my version
> is broken.
>
> Anyone with a legit. US brow
Steve Mynott <[EMAIL PROTECTED]> writes:
>You can disable 40 bit crypto via 'Security>Navigator>Configure SSL v2/3'
That doesn't necessarily work. I don't know about SSL, but it's impossible to
truly disable 40-bit RC2 for S/MIME no matter what you do - it's the Freddy
Kruger of crypto algorith
> --
> From: Steve Mynott[SMTP:[EMAIL PROTECTED]]
> On Sat, Jun 26, 1999 at 01:09:36PM -0400, Nelson Minar wrote:
>
> > The point is that in Netscape, it is very hard to tell if a given link
> > is 40 bit or 128 bit. Sure, with enough poking around looking at page
> > info you
On Sat, Jun 26, 1999 at 01:09:36PM -0400, Nelson Minar wrote:
> popped up. I was shocked to see that the certificate was being used
> with a 40 bit cypher. I have no idea what info has been leaked out
> that channel.
You can disable 40 bit crypto via 'Security>Navigator>Configure SSL v2/3'
> T
At 07:43 AM 6/26/99 -0700, David G. Koontz wrote:
>DES isn't secure how? Certainly it isn't absolutely secure, and
>probably never has been. Is it secure enough to keep a cracker from
>grabbing passwords flying by? In most cases yes. The effort for
>individuals to break DES is significant in t
I agree strongly that having weak crypto in a system is more dangerous
than on crypto. The major barrier to crypto these days is not math or
computer science, it's usability. Weak crypto creates a usability
nightmare.
Consider it from a user's perspective, mine. I trade stocks online. My
broker s
On Fri, Jun 25, 1999 at 02:32:44PM -0700, James A. Donald wrote:
| > Despite your contempt for Netscape and Microsoft, they do,
| > in fact, sell strong crypto products where they are able
| > to. If the CEOs of these companies went to their boards of
| > directors and told them that they were go
On Fri, Jun 25, 1999 at 06:48:49PM +0200, Ulf Möller wrote:
| > I'll assert that deploying DES today is WORSE than deploying no crypto
| > at all, because of the deployed lifetime of a new product, and the
| > associate removal of pressure to deploy an effective cryptosystem.
|
| OpenSSL supports
Lucky Green writes:
> 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 bel
Lucky Green wrote:
>
> 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 belie
> Besides, as the developers of open source software we can hardly
> exercise pressure on our users.
In FreeS/WAN we do. The code we ship only runs secure ciphers in
secure modes. You actually have to know enough to go in and
change the code to run insecurely. (Or, of course, you can get
your
I consider there to be a number of seperable issues:
1) Should the IETF support a weakened cipher?
2) Should DES be an acceptable weakened cipher?
3) Are there other reasons to use DES?
4) Is the legacy code issue going to be crippling?
The answer to (1) is much harder to answer when 56 bits
On Fri, Jun 25, 1999 at 01:34:22PM -0700, Tom Weinstein wrote:
> I think your view only makes sense if you are only interested in
> protecting yourself against entities who have $100,000 (or $50,000,
> or whatever) to build a DES cracking machine. If, on the other
> hand, you're also worried abou
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
Tom Weinstein writes:
> Adam Back wrote:
> > Jeff Schiller writes:
> >
> > > I presume that the TLS WG is planning to use DES to replace the RC4
> > > 40 bit cipher that was used for export compliance.
> >
> > I saw no indication that this was the case, though this sounds better
> > than just ad
"William H. Geiger III" <[EMAIL PROTECTED]> writes:
> In <[EMAIL PROTECTED]>, on 06/25/99
>at 10:29 AM, "Jeffrey I. Schiller" <[EMAIL PROTECTED]> said:
> Single DES, RC4-40, or any other weak crypto has no place in the IETF
> standards. I though these kind of issues were put to rest during t
> I'll assert that deploying DES today is WORSE than deploying no crypto
> at all, because of the deployed lifetime of a new product, and the
> associate removal of pressure to deploy an effective cryptosystem.
OpenSSL supports strong crypto. DES support is there only to allow our
users to talk t
--
At 01:34 PM 6/25/99 -0700, Tom Weinstein wrote:
> I think your view only makes sense if you are only
> interested in protecting yourself against entities who have
> $100,000 (or $50,000, or whatever) to build a DES cracking
> machine.
You assume that most businessmen are confident that al
"William H. Geiger III" wrote:
>
> I am *strongly* in favor in disabling all export ciphersuites. There is
> just no use for them. Netscrape, Micky$loth, & RSADSI may have no problem
> selling false security to their customers, IMHO the OpenSSL group should
> be above this.
>
> I really think th
In <[EMAIL PROTECTED]>,
on 06/25/99
at 08:22 AM, Lucky Green <[EMAIL PROTECTED]> said:
>IMNSHO,
>DES or RC4-40 have no business being in any IETF standard. If that means
>there won't be an IETF standard, fine. And if that means that deployment
>of a known insecure technology will be slowed du
In <[EMAIL PROTECTED]>, on 06/25/99
at 12:23 PM, Ben Laurie <[EMAIL PROTECTED]> said:
>Adam Back wrote:
>> My arguments that adding broken ciphersuites to an IETF standard was
>> in direct and obvious violation of RFC 1984 fell on deaf ears, as
>> Netscape, microsoft and even openSSL (in the
Adam Back wrote:
> > I presume that the TLS WG is planning to use DES to replace the RC4
> > 40 bit cipher that was used for export compliance.
>
> I saw no indication that this was the case, though this sounds better
> than just adding DES and leaving all the 40 bit ciphersuites intact
> which l
In <[EMAIL PROTECTED]>, on 06/25/99
at 10:29 AM, "Jeffrey I. Schiller" <[EMAIL PROTECTED]> said:
>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 stuf
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
IMNSHO,
DES or RC4-40 have no business being in any IETF standard. If that means
there won't be an IETF standard, fine. And if that means that deployment
of a known insecure technology will be slowed due to lack of
standatization, better still. Considering the alternative, a "security"
architectur
Adam Back wrote:
> My arguments that adding broken ciphersuites to an IETF standard was
> in direct and obvious violation of RFC 1984 fell on deaf ears, as
> Netscape, microsoft and even openSSL (in the form of Ben Laurie)
> busily rushed and implemented the proposed broken ciphersuites.
OpenSSL
Jeff Schiller writes:
> Actually for the TLS crowd, going to DES is a step up.
It is a step up -- right now, of sorts. But in 10 years time it will
look like a step up from ROT-13 to ROT-n (where you have to guess n).
Lucky is right on the money, as usual:
> DES or RC4-40 have no business be
Actually for the TLS crowd, going to DES is a step up. I presume that the
TLS WG is planning to use DES to replace the RC4 40 bit cipher that was used
for export compliance. Normally we would not profile a weak cipher for use
in export applications. We made an exception for TLS/SSL because it was
> Title : DES Applicability Statement for Historic Status
> Author(s) : S. Bradner, W. Simpson
> Filename: draft-simpson-des-as-01.txt
> Pages : 8
> Date: 22-Jun-99
>
> 'The PPP DES Encryption Protocol' [RFC-2419], 'The
30 matches
Mail list logo
