In the mind of the Drygerskunk

Reading the happenings of having a (MTA Maryland) MARC train set being leased to (NYC MTA) Long Island Railroad (aka LIRR) to help with summer crunches... got me thinking about exclusive local communications though cell phones, and eventually onto secure group communications.  I'll try to put it in laymans terms for those non-geeks, using some old standard-ish terminology.

Alice and Bob want to send letters back and forth, but know Craig (that NSA narc) is snooping around.  What do they do?

Well, they encrypt their messages.  To make it hard for Craig to snoop, they use what is called Public Key Encryption.  Alice makes two keys, one she keeps herself (private) and one she gives to Bob (public).  Bob does the same, giving a key to Alice.  When Alice encrypts a message, she uses her private key and Bob's public key.  When Bob gets it, he uses his private key and her public key.  The algorithm used allows this scheme to work.

Of course, I'm simplifying the issue, especially in cases where Craig may of dressed up like Bob and got in the middle of things.  But that's the essence of secure encryption.  SSL/TLS connections (used in that HTTPS connection you go to Amazon or your bank with) use PKE with a few administrative levels to make sure Craig isn't going to steal out of Bob's bank.

But what if Alice has more friends with a similar interest?  What if they want a group chat with Elen, Frank, George, and Helen about their dearly departed friend Zoe?

They could swap public keys, and have every push out every message... but that wastes time and bandwidth.

They could go though one person, like Xavier.... or is that Craig in disguise again?

Or... Alice could make another pair of keys for the group, and send both to everyone (but Craig, because he's a dick) via the existing secure messaging.  Everyone would send using their personal private key but the group chat public key, and decrypt using the sender's public key and the group chat's private key.  All they would need is someone to relay the chat to save bandwidth... and Xavier volunteered for that (the geek -- he doesn't even save connection logs).  Craig would have nothing because he wouldn't even see the group chat key being sent.

So Linden Labs is looking at megaprims (prims over 10m on an axis) and what could be done.

Without going into the problems, I'd present my solution:

• Expand the client size limit to 32 m.
• Force any over 16m to be non-physical.
  
• Ban and remove any that are 128 m or over.
• Ban any user that has a 256m or over for breaking the sim and client.

http://blog.secondlife.com/2007/10/12/the-big-prim-problem/

I now have the monitor, an Insight 19" CRT.  I'll install it later when I get home.

You know, I have some strange hardware.

Origionally, occlan was named neobast, and was a bit of a bodge job I was able to put together.  Cheap hardware, I know.  neobast died with a strange bit of HD failure which I can only pinpoint to a damaged first track which eventually is recoverable, but just.  Of course, neobast had my Wolfox Reshouter on it too.

I recently purchased a 20 gig HD, and it came in the mail earlier today (Friday, Saturday being when I'm writing this in the morning, gotta go to bed).  So I slapped it in there, checked it out, and put Gentoo Linux on hir, now occlan.

I don't know if it was Slackware causing problems, but with Gentoo, occlan shut down properly, as well as reset properly (aka I didn't have to turn it physically off to reboot it).  I'm not sure what to think of it, but if it's happy with Gentoo, I'll stick with Gentoo.