[Ffmpeg-devel] SVN challenge response authentication weaknesses

[Uoti Urpala]

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

For security this would at least require the (unspecified) AES key
derivation to be good enough not to use the shared secret directly but
to use different keys in different directions, otherwise since the
numbering is the same in both directions you could swap a packet from
the client with the same-numbered packet from the server or vice versa.
It's quite inefficient since each 128-bit AES ECB block would need to
contain a sequence counter big enough to avoid repeats (I think this is
enough to make such a scheme undesirable in practice).

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

If you want to create a fixed version before announcing a security
vulnerability. Also proprietary development is not the only alternative
to opensource development: some uses can be private (people keep various
personal things under revision control systems).

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

Yes, but if you think encryption and secrecy are desirable then it's
better to do them properly.

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

In practice you would likely have enough known plaintext to get lots of
known targets for bruteforcing the AES key.

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

It's a known method and designed for authentication, whereas custom
schemes should be viewed with suspicion. It allows an implementation
with much less overhead (minimum 1 authentication block for each
communication phase, whereas your scheme would require a counter for
each ECB block containing 128-counter_size bits of useful data).