In the first two parts of this covered the idea of security and physical security.  We now move into access security.  Access security is a highly religious topic, bent with emotions, misinformation, egos, principals and typically (worthless) corporate policy so prepare for battle on this one if you dare tackle it.  Let's dive right into this using our previous example of an office building and I'm looking for a port to plug into the network.  How long will that take?  Virtually no time, they're everywhere, which leads me to my first not-really bold statement of this post.

Network access cannot be controlled.  More...

In this world we live in today, there are many issues that hit in the security realm but I'm astonished at how the same issues keep coming up so I feel it's necessary to go over them as best I can.  Some things may shock you, freak you out, piss you off and generally make you think I'm full of it. More...

A friend of mine got pulled over the other day, maybe a half mile behind me.  When I heard the officer gave him a ticket for 78mph, my first response was "no way in hell".  I'm good at math, so I decided to prove it with numbers.  Take notes, you can use this because its math.  Numbers don't lie (if you don't screw up).

Trig teaches us a couple useful things.  First, one of my favorite equations, A² + B² = C² - this tells you the length of sides of a 90' triangle, C being the hypontenuse.  What does this give us?  Everything we need, IDDQD, I win.

When the officer was tagging people, he was outside the far RIGHT lane, not the usual left lane, being head-on with normal, would-be speeders -- this is a fault of the officer I intend to prove with simple math.  There's also a fundamental flaw in lasers - they ONLY measure the velocity of an object realitive to the device, a perfectly straight line (ok, maybe off by a degree or two, but thats neglegable) -- that's why most officers sit in the left side.  I'm going to first establish the area, and some measurements thanks in part to Live Maps.  These are estimates, but a lot safer than actually going out there and measuring

5pm on I71 south bound on the north end is a bit of a mad-house and usually lasts until 6-6:30 (duh, normal rush hour).  People coming out of Polaris heading home, hitting 270/161/etc makes it a bit on the heavy side if you can't get out before 5.  I'd call it modertate traffic - you aren't changing lanes much and when you do, it might take a few seconds to get over.  Not exactly high-speed territory.  More over, the officer isn't going to get a good clean shot to someone that's floating down the highway in the left lane, especially during this time which doesn't play into his favor.

Here's the area.  The officer sits on the far right, he's in the left lane.  He estimates he was about 100yrds ("about a football field") when he got tagged, which considering the traffic volume, I'd say thats possible.  He also estimates he was going around 70, not 78.  Lanes of traffic in that area are about 30 yards wide.  We have our math.  So let's start with using a perfect triangle (which, as you can tell, its not, we'll get to that).

Using our simple math of 100² + 30² = x², our math comes out to 105 for X.  So how fast was he going realtive to the 100yard side?  Easy - 78mph / 105 = X / 100.  This number comes out to about 74mph which is a huge thing.  In Columbus (maybe even the entire state), 10 over is two points on your license, under that is only 1 point and that turns out to a difference on your insurance -- they frown on tickets.  Now you could argue he said he was 100 yards away from the officer, and you'd be right, but comes out to about the same, the lower end of 74mph.

But there's a problem.  The road curves off to the left (east) meaning it isn't 30 yards at the base of the triangle.  By my guess, conservatively, it's 50 yards.

100² + 50² = X² comes out to 111.  78 / 111 = X / 100 comes to ~70mph.  Hmm, that's barely over the limit.  And if you again say "well, he said 100 yards" -- comes out to 67.1mph so by my basic, easy math, from where the officer was and the speed he recorded it COULD be anywhere from 74mph to 67.1mph - granted, yes still technically speeding, but NOT 78mph. You could also argue the officer tried to line up the left lane with where he was, which is plasuable, BUT with the heavier traffic ...I don't think that's realisticly possible to aquire a car though the traffic of that volume.  Hmm, maybe I should send this off to mythbusters?

For those of you who don't know, I have a degree in EET which more or less means I'm a much bigger nerd than I appear and every once in a while I see things on the web that really spark my interest on the EE side and this is very much one of them.

A quick overview of how phones work -- you are given a certain frequency range (3k I believe) which runs on top of a larger pipe (T1).  Within this pipe is a given frequency range and 24 channels, each channel has a guard band and 3k in each direction giving you a total of 8k of space (3k + 3k + 1k guard + 1k guard).  If you do the calculations, you'll find out how a T1 = 1.544mb.  Anyway, a nasty thing that can happen is cross talk.  This is when a given channel starts to flux outside of its given range and past the guard bands -- and thats very bad, you can begin to hear others conversations (who needs wire tapping eh?).  Anyway, when its running perfectly (or close enough), you'll never experience this, but it can happen.  Slight tangent, each channel is 64k which is also 1 voice channel and one channel of an ISDN line, sometimes called "fractial T1" depending on how is packaged (...or priced) but how you only get 56k over a phone line?  Hint - guardbands.

Anyway, ADSL works on regular phone lines at different frequencies, more specifically higher frequencies but there's a limit.  Well, this guy in Australia has figured it out.  I'm guessing he's using some kind of codec (encoder, kind of like what you use to create MP3s and videos) to jam more info into the same space with a little overhead.  Allow me to explain how this would work.  Say you have a text file with ...250k of info.  You would like to submit this file over some medium (flash drive, cables, whatever) but your limit is 35k, no more.  How would you do this?  Oh, there's a magical thing called "zip" that compresses that info into a much smaller space using a set of calculations/rules to reduce the size.  Yay that works, it cuts your file size down to under 35k and off your data goes.  When the recipient recieves this package however, it must know how you reduced (assuming it needs to, or more importantly, IF if even needs to uncompress) the payload.  If this is the only way to transmit, this is no problem otherwise another piece of verification must take place somewhere within the system, typically at the endpoint. As with anything, there's a catch -- the overhead.  Obviously, you shouldn't use a heavy heavy codec because that takes processing time and can slow down a system instead of speed it up.  Say for instance you are converting a movie of you took of your little ones into a file on your desktop.  Lets say native comes out to be 4gb (you're cool, you got an HD camera).  If you run it though a codec with some loss and convert it to ...700mb.  A good file reduction but now the codec to run it takes up 85% cpu to run.  Hmm, not a good trade off.  Another codec offers 1.2gb but only a 15% cpu usage when you run it.  Of course, you will have to consider your expected end point (is it a CD or DVD for instance).