[Ffmpeg-devel] SVN challenge response authentication weaknesses

[Uoti Urpala]

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
specify the key management in too much detail; I assume you meant a
shared 128-bit secret that is copied to both machines, 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...). 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.