On Sat, 2004-04-17 at 01:31, Pavel Roskin wrote:
> On Fri, 16 Apr 2004, Robert Denier wrote:
>
> > If anyones interested in an orinoco based driver that uses AES
> > encryption and different keys for every path then you may wish to take
> > a look at
> >
> > http://www.umr.edu/~denier/ses
> >
> > IMPORTANT: This breaks compatibility with other 802.11 communications.
> > If a person wants to use this, they need to use this on all their
> > computers they want to comunicate with this.
>
> I think it doesn't need to be so intrusive. You could just have a private
> setting to select or deselect your advanced encryption. No need to remove
> __orinoco_ev_rx() and orinoco_xmit() from orinoco.c. Just check if SES is
> enabled and if so, call the encryption or decryption function.
A reason against that idea is by allowing options you allow ways to
configure things in an insecure manner, however I agree that one is well
worth it.
I'll have to eventually set many things outside the source code, although
how to do that isn't something I've entirely figured out yet. For the next
major revision I'll eventually need to be able to parse a file with
mac id's, public keys, and ips. I was thinking to use the proc interface
for those... Still before I get there, there will be another revision
that just hard codes things again, but adds in public key encryption.
> It looks like you broke monitor mode because you replaced the whole
> __orinoco_ev_rx() function. Monitor mode may be useful even with the
> security enhanced driver.
Oops. I confess that when I was figuring out the orinoco code I
eventually started it with the delete key and then
added stuff back in. I must not have added back in monitor mode.
> Using local_fake_mac instead of dev->dev_addr may be fragile. The driver
> assumes that dev->dev_addr is the MAC address currently used by the
> hardware. Better set dev->dev_addr to whatever you want.
So setting dev->dev_addr doesn't change the value the system sees with
ifconfig and the rest? I was afraid it would and cause trouble.
> You may need to
> preserve the original value if you are going to use it later.
Eventually I intend to somehow do a device reset (or whatever is needed
to change mac's safely.) at some interval (2 hours?). This will include
dropping off the network, generating a new fake hardware address and
going back on the network. I can't think of any major downside to this
approach and it does meet my goal of obscuring who is sending traffic to
whom without violating the 802.11 spec. (Well a minor downside is a brief
interruption in traffic, but its the best I've thought of so far.)
One of the reasons I posted this publicly was for feedback, although
I don't want to spam your list too much either. I do wonder why
I haven't as yet got a copy of my previous message back to
[orinoco-devel] but since other people did I suppose thats ok.
The more I think about it the more I like the idea of an iwpriv option,
since I won't need to switch drivers when I'm doing a comparison.
I guess I'll give that a higher priority.
-Robert
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
|
