[Ffmpeg-devel] SVN challenge response authentication weaknesses

[Michael Niedermayer]

Hi

On Mon, May 29, 2006 at 01:39:31AM +0300, Uoti Urpala wrote:
> On Sun, 2006-05-28 at 23:55 +0200, Michael Niedermayer wrote:
> > 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
> 
> You did, at least enough to make it less secure than the best solutions.
> You didn't mention authentication at all; an attacker that can modify
> packets could modify commit contents if he knows enough about the
> plaintext (assuming an usual xor-based AES chaining mode). You didn't

i was rather thinking of ECB mode where AFAICS this isnt going to work


> specify the key management in too much detail; I assume you meant a
> shared 128-bit secret that is copied to both machines, 

yes


> and AES keys
> derived from that appropriately (the omitted key derivation details
> could have extra weaknesses; also note that you need a different secure
> protocol to be able to transfer the secret file...). 

gpg, the advantage is that the software on the server stays simple and
independant


> Your scheme has no
> forward secrecy: all recorded past transfers are compromised if a key is
> leaked, even if it is removed from use immediately. This might not
> matter for ffmpeg use where secrecy doesn't matter much but is certainly
> undesirable for a general solution.

yes, its not an issue for opensource so i dont see why we should care ...

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