North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Carnivore Update - Washington Post 11/21/00

  • From: Mathew Butler
  • Date: Mon Nov 27 05:26:35 2000

Title: RE: Carnivore Update - Washington Post 11/21/00

The _NSAKEY symbol in Windows does not affect the keys used or generated for WinInet() or CryptoAPI calls.

128-bit open source is subject to a license exception, and can thus be examined to a fare-thee-well.

I agree that the close-source nature of the CryptoAPI (and thus, crypto smart cards, and the underlying crypto libraries) is detrimental to its security evaluation.  Thus, I am unwilling to state categorically that it is a secure implementation.

But, Carnivore doesn't have the capability of decrypting anything, merely decoding the packet headers.  It can capture all traffic by a suspect, including the SSL-encrypted payload; however, this means that the full protocol exchange must be analyzed and cracked, and any session renegotiations must be analyzed and cracked as well.

SSLv2 was (and is) insecure.  Now that the RSA patent has fallen out of protection, it's going to be more possible to use open-source (and other) software that implements SSLv3 and TLS1.0; regardless, old standards die hard.

However, I could get into a debate over whether 'self-signed certificates are insecure'.  This is not the place.

Just clearing up some misapprehensions,

-Mat Butler

-----Original Message-----
From: Philippe Landau [mailto:[email protected]]
Sent: Thursday, November 23, 2000 1:26 PM
To: [email protected]
Cc: Eric Murray
Subject: Re: Carnivore Update - Washington Post 11/21/00



>> of course carnivore has no problem decrypting SSL.
>Source, please.
(this seems obvious for the still widely distributed 40 bit versions.
there are many sources discussing the NSA key in windows
and apple is likely to have implemented similar backdoors.
there could be a reason why 128 bit SSL encryption has
been approved by the US for export in december 1999.
the question is if we have to prove they can decrypt SSL communications
or if the government agencies have to show they can't
(don't hold your breath).
how strong 128 bit encryption is is another question.)
this discussion is probably getting off-topic on this list.
i have just received some thoughts about it from security expert
Eric Murray and while he is less pessimistic, please see below.

kind regards     philippe, http://A-Z-Internet.com

            --- *** ---
http://remus.prakinf.tu-ilmenau.de/ssl-users/archive14/0158.html
http://www.mail-archive.com/cryptography-digest%40senator-bedfellow.mit.edu/msg02375.html
http://www.tinhat.com/surveillance/code_breaking.html
SSL Server Security Survey - A random sample of 8081 different secure web servers (servers running the SSL protocol) in active use on the Internet shows that 32% are dangerously weak. These weak servers either support only the flawed SSL v2 protocol, use too-small key sizes ("40 bit" encryption), or have expired or self-signed certificates. Data exchanges with all types of weak servers are vulnerable to attack.

http://www.meer.net/~ericm/papers/ssl_servers.html

            --- *** ---
On Thu, Nov 23, 2000 at 08:55:52PM +0100, Philippe Landau wrote:
> Hello
>
> Is there a possibility that a government
> has a backdoor to decrypt SSL communications ?
>
> kind regards     philippe, http://A-Z-Internet.com

Yes it is possible, in the code that calls SSL.   It's not very possible
in the SSL protocol itself since that has been well investigated by
security researchers.

It's a little more possible in open-source SSL implementations
but still not very likely.  It's most possible in closed-source
implementations, where the code that calls SSL is
only known to the author(s).  A backdoor that say reduced the
entropy going into session keys would be difficult to detect--
even decompiling the code and stepping through it might not show it.

--
  Eric Murray           Consulting Security Architect         SecureDesign LLC
  http://www.securedesignllc.com                            PGP keyid:E03F65E5