Re: Potential vulnerabilities of the Microsoft RVP-based Instant Messaging

From: Justin Moebus (jmoebus@EAGLEOPTICS.COM)
Date: 03/21/02 

Date:         Thu, 21 Mar 2002 14:02:32 -0600
From: Justin Moebus <jmoebus@EAGLEOPTICS.COM>
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

not with realtime encryption. this could work just like other
implimantations - example: military tactical traffic uses keys in the 40 to
64 bit length range, whereas the us cencus data is encrypted using the
longest keys imaginable (4096+ bit)

what's the relevancy? military tactical traffic is realtime and is pretty
useless after a few hours or days. That means you'd have to make sure the
secrets are kept for at least that long but to keep the system operating at
realtime speeds, you keep it short enough to allow the computers to actually
do the encypting/decrypting in realtime as well.

The cencus on the other hand is different in the sense these by law must be
kept secret for 100 years - that takes a much longer key to ensure this
protection, but sacrifices the speed at which en/decryption can be done.

Thus, to say its impractical to use encryption on IM is not true in a
general sense. More specifically, you can't use really long keys without
bogging down the processor making the process slow to a crawl. You can
however use short keys that allow for the speed you need at a sacrifice of
security - not loosing it all, just lowering the average time a brute force
attack would take. Unless its the NSA or something like that, the chance
that your enccypted IMs are even going to be given the effort is nill
because the powers that be have to choose their battles like everyone else.
So leverage that fact, and make them have to work for a living if security
is a concern, just pick short keys for the actual traffic and long keys for
identification and message key exchange.

These methods are built right into things like PGP and such - the methods
are very old school and extreamly well tested/desinged. You would
basically, just migrate the traffic being sent through the
encrptor/decryptor to be IM traffic. With today's state of the art being
around 2.0 ghtz with about 512 to 1024 mb memory, resouces shouldn't be an
issue for shorter keys.

Also, the speed of encyption as key length increases is a linear function,
however, the average time needed for an exahustive brute force attack
increases exponetially as key length increases - not as big of a hit on your
processor as you may think.

In the end, the likelyhood a sucessful attack being based on the actual
algoruthm or key is slim when compared to the numerous other ways the same
protected information can be obtained. Sometimes you concentrate so much on
the algorythem and keylength, the security of the program using them goes
out the window. Things like key managment: it doesn't do any good to even
bother with encryption if you haven't concidered secure storage of the keys
right? its a system that needs to be concidered as a whole, not as
components because any attacks will go after the week links, not the strong
ones - don't put all the eggs in one backet so to speak.

-Justin

-----Original Message-----
From: Michel Arboi [mailto:arboi@YAHOO.COM]
Sent: Thursday, March 21, 2002 10:29 AM
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: Re: Potential vulnerabilities of the Microsoft RVP-based
Instant Messaging

 --- Greg Corey <gregc@TARASOFTWARE.COM> a écrit :
> Instant Messaging is intended as a faster alternative to SMTP E-mail
> -- in that context, an expectation of any level of security greater
> than that offered by SMTP seems unrealistic.

Just FYI: Reuters plans to add instant messaging to its financial
desktop.
http://www.itworld.com/App/299/IW010322hnreu/

Their IM can interoperate with MSN Messenger but they use SSL. This
should solve the problem of confidentiality, server authentication (and
dynamic ports too?!)

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

Relevant Pages