[Ffmpeg-devel] SVN challenge response authentication weaknesses

[Roman Shaposhnik]

On Mon, 2006-05-29 at 01:32 +0300, Ivan Kalvachev wrote:
> 2006/5/29, Michael Niedermayer <michaelni at gmx.at>:
> > Hi
> >
> > On Sun, May 28, 2006 at 11:34:40PM +0300, Ivan Kalvachev wrote:
> > [...]
> > > The absence of strong cryptography protection for the svnserve is huge
> > > drawback. Today when RSA cryptography is widely deployed it is insane
> > > to use so weak hashing. I have no idea why svn authors haven't
> > > provided ssl/tls solution yet.
> >
> > iam curious why every problem has to be attacked with the most complex mess
> > available ...
> >
> > why not simply encrypt all communication between server & client with AES
> > using a _random_ 128bit key which on the client side could be encrypted
> > with a plaintext password to add a little extra protection in the case
> > the client gets compromissed ...
> > also add sequence numbers too all packets to protect against
> > attacks which involve replaying packets
> >
> > all passive sniffing should fail as it would require breaking AES
> >
> > recording and replaying part of the stream would fail due to missmatched
> > seq numbers which an attacker can not modify or read as they are within
> > the encrypted area ... not that replaying a stream seems overly dangerous
> >
> > a man in the middle style attack should fail too as the attacker can
> > neither make sense of the packets nor generate any valid ones
> >
> >
> > did i miss something? this seems alot nicer then a SSL/TLS dependancy
> 
> Without been expert or even advanced user of ssl/tls I can tell you
> that they actually do that.
> 
> Here the problems is that the _rundom_ key must be know for both
> server and client. It must be transmitted from one to the other. So
> they use RSA (or in other words system with non-symmetric keys) to
> authenticate each-other and transmit the master-key securely. Then
> they can switch to use some less computationally intensive algorithm.
> 
> Well, you know, you can reinvent the wheel and hot water.
> But giving that there are already well tested steam locomotives out there...
> ;)

Worse yet it seems that every attempt to reinvent this particular wheel 
fails for one reason or the other. For more details see:
    http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt

Bruce Schneier had a similar write up but I can not find it at the
moment. Granted, I'm not a security expert (although I dable it it)
but I respect Bruce and Peter and I trust their judgement. 

Thanks,
Roman.

P.S. Also, the very last thought at the very end of the write up
is worth the entire read, IMHO. ;-)