[Ffmpeg-devel] SVN challenge response authentication weaknesses
Mon May 29 00:51:41 CEST 2006
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:
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.
P.S. Also, the very last thought at the very end of the write up
is worth the entire read, IMHO. ;-)
More information about the ffmpeg-devel