[Ffmpeg-devel] SVN challenge response authentication weaknesses

[Ivan Kalvachev]

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