> -----Original Message-----
> From: Michael T. Babcock [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, 4 February 2001 2:36
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'John
> Steniger'
> Subject: Re: Configuration Arguments... In House...
>
>
> [EMAIL PROTECTED] wrote:
>
> > Being a little picky here - but SSL does not prevent sniffing. The
> > encrypted data that can
> > be sniffed has to be decrypted to be of any use. Provided
> you have a
> > "strong" algorithm
> > and a sufficient encryption level to make a brute-force
> attack futile (40
> > or 56 bit would not
> > be sufficient), the data should not be able to be
> decrypted. Just my two
> > cents.
>
> Side note (adding to what you said):
>
> SSL traffic can be sniffed. The sniffer just gets encrypted
> traffic. The sniffer can then decide to cryptanalyse or brute-force
> the packets (cryptanalysis better because of known/guessable
> header contents in starting packets)
That's incorrect. Guessable headers are only useful if someone has made a
boneheaded implementation mistake. In short, CBC (Cipher Block Chaining)
solves this problem.
In long, all the SSL/TLS ciphers must be used in CBC mode, which means that
the first block of data to be encrypted is a chunk of random garbage (called
an IV, or Initialisation Vector). Although it seems wrong at first glance,
this garbage doesn't need to be secret - just random and unique. The first
combination of the garbage with the algorithm and the secret key produces a
new string of garbage which cannot be guessed from the first garbage without
knowing the key (this is a basic property of strong symmetric ciphers). This
new garbage is then XOR'ed with the first block of plaintext before it is
encrypted. This has the effect that even if you know the first block of the
real plaintext, it doesn't help you at all since the thing that's being
encrypted is actually the _combination_ of the encrypted IV and the
plaintext and you can't guess the encrypted IV - capish?
> at their leisure. If your data
> is sensitive enough (SSN's should come to mind), the amount
> of time to brute-force a standard SSL connection (even a "high"
> security one) shouldn't be considered good enough.
I've got some issues with this. SSL / TLS supports "good enough" encryption
to be used confidently in situations where you need a 10 year
confidentiality window. 128-bit IDEA is off the scale in terms of current
cryptanaylsis / brute force capability, which gives it at least a 15 year
safety margin, depending on your level of paranoia. TLS will support AES as
soon as the IETF are done writing it into the standard, which conservative
pundits rate as good out to 2030 or so. IMHO a thirty year window is crap,
especially given the cryptanalysis scares surrounding AES, but it gives you
an idea.
Remember that each session has PFS - your attacker can only crack one
session at a time, unless they break the public key of the server you're
using, in which case they can get at any session _with that server_.
> If your
> attacker cares to and captures all of your users' traffic for two
> years and spends 10 years in the background cracking it all,
> they may have information that was worth the wait (especially if
> they're selling identity changes, etc.).
Based on current tech, 10 years wouldn't be enough. In fact, based on
current tech your grandchildren would be dead before you'd need to worry
about it.
>
> SSL's encryption strength needs to be severely re-thought in
> light of current uses and future uses of encrypted web traffic.
It already has been. The recommended minimum public keysize has been bumped
up again from 768 to 1024 and I'd expect another bump to 1536 in the next
few years. AES will address the symmetric key worries, with 3DES likely to
be available for paranoid / retrograde users.
> --
> Michael T. Babcock (PGP: 0xBE6C1895)
> http://www.fibrespeed.net/~mbabcock/
Cheers,
--
Ben Nagy
Network Security Specialist
Marconi Services Australia Pty Ltd
Mb: +61 414 411 520 PGP Key ID: 0x1A86E304
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
