On Mon, 2008-12-22 at 15:39 +0100, Henning Rogge wrote:
> On Montag 22 Dezember 2008 15:22:08 Bernd Petrovitsch wrote:
> > Today? Yes.
> > Tomorrow?
> > Given that WEP, WPA and WPA-2 are already there (and the former 2
> > already obsolete), more of that will come.
> >
> > > story... ;)
> >
> > VIA-C7 - http://www.via.com.tw/en/products/processors/c7/ - has hardware
> > AES support.
> Which does not help with asymmetric algorithms.

Exactly. If you strive for a high throughput solution, you use symmetric
algorithms for the bulk data (as e.g. pgp, gpg, ssh, IPsec, openvpn do
since ages) and use the asymmetric keys to exchange them, sign, etc.

> > Apart from that: The asymmetric keys are just necessary to (regularly)
> > exchange the symmetric ones - IPsec does this also in completely
> > user-space (at least 5 years ago).
> Yes... because IPSec mostly deals with unicast traffic. Multicast (broadcast 
> is a special case) is MUCH MORE difficult.

Yes, because you have to have different (symmetric) keys for each
multicast group and change the key if one joins or leaves the group. And
there are probably more similar problems.
Let alone to *guarantee* that no one uses the old one ....

There are year old thesis' and probably lots of papers available ....

> > And for the symmetric keys, the algorithms are fairly cheap (and one
> > could use a somewhat less secure but much more CPU-saving one if it
> > really matters).
> > So personally I consider that problem as such solved - it is just a
> > question of a good implementation (or hardware support).
> Sorry, but you are dead wrong.
>
> The problem of securing OLSR-traffic is to authentificate netwide broadcast 
> floods... you cannot do this easily with symmetric algorithm if you Want to 
> protect against an insider attacker.

Oh, no one said that symmetrical algorithms alone will solve the whole
problem - they are just a means to reduce the necessary CPU usage (or
ASIC usage if it comes to hardware implementations).

For a conceptual analysis/design, we can simply ignore the CPU usage
points[0] since I consider *these* are solved (as mentioned above) -
they may not be implemented right now but that can be added as it is
only a performance improvement (and no design change).


For the "big picture" (which is IMHO addressed by the thesis + plugin)
the question is, which problem should be solved under which conditions.

Personally, I don't think that "define a netwide key to sign all other
keys" is a viable approach at all (unless one wants to establish a
monopoly).

And the distributed approach boils down to "how do we get the web of
trust - similar to pgp/gpg - to work and which organizational issues
have to be solved".

And to the worst, all of these (technical) approaches have the problem
that they should (IMNSHO must) also fit to and *support* the
organizational situation (which may be quite different between different
wireless networks) and not *define* the organizational structure just
because it is implemented (badly) that way.
And with that we are IMHO far away from pure mathematics or how many CPU
cycles are burnt too much  ....

So please define "trust" for mesh networks;-)

	Bernd

[0]: I just answered them as the seem to be *abused*/*misused* for
     negative arguments.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




