[Ffmpeg-devel] SVN challenge response authentication weaknesses

[Michael Niedermayer]

Hi

On Mon, May 29, 2006 at 05:04:20AM +0300, Uoti Urpala wrote:
> 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.

that could be trivially done by simply generating 2 independant 128bit
keys initially (= 1 256 bit key)


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

ok, this is flaw in my suggestion, so lets xor the counter into the key
instead
first packet from the server contains a encrypted 128bit seq value, both 
server & client use that as initial value for counting (we could replace 
the +1 with something more complex if you are afraid from related key attacks)


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

ok i agree there are cases where strong encryption would be desireable


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

yes, i fully agree, still its an interresting excercise to see where my
custom scheme fails, you already found one big flaw (the seq num overhead)
can you find another in my new system? :)


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

yes, this is a flaw in my system, somehow i didnt realize it ...


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