[Ffmpeg-devel] SVN challenge response authentication weaknesses

[Michael Niedermayer]

Hi

On Mon, May 29, 2006 at 03:24:50AM +0300, Uoti Urpala wrote:
> 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? 

no

my idea which may have its flaws was that the server would choose a random
initial number and then both client and server would use that as initial
seq number for that connection and then just add +1 relative to their own 
last sent packet


[...]

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

could you provide a concrete example where keeping svn data secret makes
sense for opensource development?


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

i dont see where HMAC(-md5) is supperior to AES

* AES would provide some additional data encryption
* both AES and HMAC would be susceptible to bruteforce attacks if the 128bit
  ranodm key would be replaced by a plaintext one, actually HMAC might be
  more susceptible as more data is known, for AES you must guess the content
* both are susceptible to replay attacks if no sequence number is provided
  again HMAC seems more susceptible, as the seq number is known where for
  AES its not

so please elaborate on where you think HMAC would be supperior ...

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