[Ffmpeg-devel] SVN challenge response authentication weaknesses

[Michael Niedermayer]

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

[...]

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