[Ffmpeg-devel] SVN challenge response authentication weaknesses

[Michael Niedermayer]

Hi

On Sun, May 28, 2006 at 03:51:41PM -0700, Roman Shaposhnik wrote:
> 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.

yes but that key exchange is needed just once and gpg over email seems
like quite effective for that ... and please keep in mind
security requirements for SSH/SSL differ from SVN, keeping the content
secret for example is irrelevant


> > 
> > 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. 

me too and i dont doubt my system invented in 10min is _significantly_
less secure then SSH/SSL not to mention its not equivalent at all
as it leaves the key exchange to an external program (gpg)
i never claimed it to be as secure as ssh/ssl 

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is