[Ffmpeg-devel] SVN challenge response authentication weaknesses

[Uoti Urpala]

On Mon, 2006-05-29 at 01:33 +0200, Michael Niedermayer wrote:
> > 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

In ECB mode without authentication you could still at least corrupt the
contents. Depending on the details of the incompletely specified
sequence number scheme you mentioned further attacks that allow creating
known security vulnerabilities in the repository code are most likely
possible too. Did you intend the sequence numbers to keep state between
connections? If so then keeping track of that is an additional
implementation hassle (and nontrivial to do right if the other side
might sometimes not be the intended recipient).

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

Encrypted communications can make sense even if you primarily work on
opensource software. It's certainly not limited to companies doing
proprietary software development only. So such a scheme is flawed as a
general solution.

In fact, if you want to protect the repository against tampering but
don't care about secrecy then I think you made a fundamental design
error in using a cipher but no authentication codes. Replace the
encryption with a HMAC and you'll have something that better matches
your goals (though details might still need tweaking to make it safe).