On Tue, 2008-12-23 at 16:03 +0100, Henning Rogge wrote:
> On Dienstag 23 Dezember 2008 15:01:22 Bernd Petrovitsch wrote:
> > > A group key does not allow for athentification within the group, so it's
> > > useless for securing OLSR routing packages against attackers inside the
> > > network (because they will have the group key).
> >
> > Well, for signing large data chunks, the usual hack is to calculate a
> > (relatively) cheap checksum (e.g. MD5[0], SHA-1, ..) and sign that.
> > And if the packets are not that large (so that an additional checksum
> > field seems too expensive), signing the packet as such should be fast
> > enough too.
> > Of course the performance will drop compared to an "unsecure" net like
> > today - but everything comes at a price IMHO.
> A single asymmetric crypto operation with MINIMAL data length does take too 
> long to use it for a large meshnet. Of course you don't sign the package, you 

Well, than that type security is not feasible (or one needs other - more
CPU-powerful - nodes).

> sign the checksum of the package (plus a nounce), but this doesn't help at 
> all.
> 
> The attack vector of insiders in a meshnet is to forge packages for other 
> nodes, this way you can redirect traffic, create routing loops or just prevent 

Well, that's the background for the web-of-trust problem. A new node
must gain some credibility to establish "trust" - if it needs 6 months
for that than it will take that long.
That's the background of the sentence 'please define "trust"'.

But exactly that's the main problem: IMHO the technical debates may just
lead to ideas what is (technically) possible under which assumptions and
compromises.

The to be answered question is IMHO more like: What do people want/need
for a "trusted" or "secure" mesh net?
In short: A (complete and consistent and unambiguous) specification is
needed (and not only an analysis of "what is possible" and "why not"
perhaps taking development time in to account) beforehand to define the
goal of the whole venture.
And then one can decide if that is feasible and/or useful and/or not.
And which attacks are not covered (like jamming of the signal at layer
1).
And ruling anything out beforehand (with whatever reason[0]) sound like
manipulation to me to force any decision in a certain direction.

> another node to participate in the network.
> 
> You CAN NOT prevent such an attack with a group key...

Then you need more keys.
The key question is IMHO and I'm just repeating someone else(): Which
attacks should be handled?
And there is no such thing as "100% security" (and for sure not
plug-n-play). So where do you/I/we want to compromise?

	Bernd who should read the thesis from the top of the thread

[0]: Especially things like "CPU performance" which increases
     permanently. Perhaps it's enough to sign/check every 10 packet
     to maintain the implemented trust model. Or just random checks
     to reduce the necessary CPU power.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




