you are mixing up the session key length which is 40 or 128 bits with the
RSA key length which is normally 1024 bits
the only reason anyone still uses a browser with 40 bit encryption is that
they are to lazy to get one with full encryption (or they live in iraq
basicly). due to the export restrictions being lowered it is now possible
to get the full 128 bit browsers easily. I think the computer sellers are
now including 128 bit browsers on new machines (I know some are, I don't
know if all are or not)
pwople who don't bother to get a browser with 128 bit encryption also
probably don't bother to update their browser when security holes are
found in the older browser so I don't see how anything can possibly
protect them.
David Lang
On Mon, 5 Feb 2001, Michael T. Babcock wrote:
> Date: Mon, 05 Feb 2001 09:21:15 -0500
> From: Michael T. Babcock <[EMAIL PROTECTED]>
> To: Ben Nagy <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: Configuration Arguments... In House...
>
> Ben Nagy wrote:
>
> > > 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)
>
> > plaintext and you can't guess the encrypted IV - capish?
>
> Capisco ... I won't get into it here, because that wasn't my main point ...
>
> > > 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 ...
>
> > 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_.
>
> I should have been more specific. I assumed they would attack your public key
> -- and that was my issue ... 40 bit keys (most commonly used still) and
> eventually 128 bit keys should not be considered 'sufficient' to defeat an
> attacker willing to set aside ressources for 10 years to get all the SSN's that
> went down your pipe (as per my example).
>
> > > 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.
>
> 40 bit RSA key? No problem.
> 128 bit RSA key? Not much of a problem ...
>
> > > 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.
>
> And yet browsers are shipped supporting 40 or 128 bit keys ...
>
> --
> Michael T. Babcock (PGP: 0xBE6C1895)
> http://www.fibrespeed.net/~mbabcock/
>
>
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
