In message <42609D54.6020607@optusnet.com.au>, Dmitri Nikulin writes:
>Steven M. Bellovin wrote:
>
>>DSA requires a high-quality random number in every signature operation; 
>>if the attacker can figure out that number, he or she can recover the 
>>signing key.  If you have enough high-quality randomness lying around, 
>>you're fine -- and if you don't, your cryptographic keys aren't going to
>>be very good, either.
>>  
>>
>Do both ends matter in this generation?
>The server has a hardware random number generator and NetBSD, most
>clients are Windows with PuTTY (which says it has a way of doing DSA
>without relying on entropy). So I'm not quite sure how that is. Might
>switch to RSA before it's too late.

Each side signs its part of the exchange, so the other side knows 
there's no man in the middle.  Possibly, an enemy could recover the 
client's private key, which would let it impersonate the client.  It 
is, however, quite plausible that PuTTY is doing the right thing in the 
presence of insufficient entropy.  The trick is quite simple -- store a 
a cipher key on your machine and use it to drive an output feedback 
loop.  Of course, you have to store the output of each iteration, but 
that's not hard.

Yes, there's a risk of that key and feedback variable being 
compromised.  The risk is greater than for the DSA secret key, since 
the latter is generally protected by a passphrase.  Again, though, the 
weak point is host security.
>
>>AES is far from the weak point.  I'm much more worried about the rate of secu
>rity holes 
>>in pkgsrc.
>>
>>  
>>
>That's why I'm trying to keep the package installs lean on the server
>machine, but there's very little I can do about the Windows clients.

Right.  That is *the* weak point.  Can you force your users to use 
Firefox or Opera instead of Internet Explorer?  Can you teach them not 
to click "yes" just because some pop-up asks them to?  Do they 
regularly run AV software, anti-spyware software, etc.?  Are they 
running SP2 with the firewall turned to "paranoid"?  Do ythey have 
their machines set to auto-download patches?
>
>My strategy is to separate the wireless attackers from the ones that
>could attack from the internet (either distributing trojans or attacking
>Apache and OpenSSH directly). This is naive but it's much simpler this
>way. The Windows clients are a significant weakness. I am turning off
>NetBIOS on all of them to at least make it less obvious to anyone
>watching the signals that they're shoddily-done Windows XP installs, and
>this data is broadcast (literally) outside of the tunnel at regular
>intervals of X "Microsoft Minutes".
>
>One of the Windows rigs will have to do IPSec with 3DES, which isn't
>fun, but certainly gets the job done better than WEP. What turned out
>the be the major problem with ARC4? Or was it just WEP's implementation?
>It seems very lazily done by some engineer with no real-world or even
>theoretical cryptography experience at all, and yet became a standard.
>And most people don't know any better.

WEP is a case study of why you really need to get some crypto 
specialists involved when you're designing a cryptographic protocol.  
The WEP folks made at least three serious mistakes, though one of them 
-- that RC4 isn't as strong a cipher as had been thought -- was 
unpredictable.  Several of the problems are described in
http://www.isaac.cs.berkeley.edu/~iang/pubs/wep-mob01.pdf ; the 
mistakes made there are, to be blunt, evidence of extreme inexperience. 
The cryptanalytic attack is described in
http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Rc4_ksa.ps
and the way to use it to attack WEP is in
http://www.isoc.org/isoc/conferences/ndss/02/proceedings/papers/stubbl.pdf

		--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb