Complexity and chance

In one of the Miles Vorkosigan books, the main character has a device installed in his brain and a remote that can trigger a seizure - he needs that because otherwise he would get uncontrolled seizures, usually at moments of high stress (when that's the last thing he needs). One of his problems is having that remote triggered accidentally, so the doctors assure him they coded the connection - no random signal can trigger the seizure, only the remote.

What are the possible dangers here?

1) Accidental signals that would match the frequency of the brain device, thus generating a false positive.

How does one defend against this possibility? A small code of some sort is usually required for triggering the functionality - like the 4-digit code I have to enter when my Nokia cellphone locks the keys (to prevent me from accidentally dialing out when I keep the phone in my pocket).

2) Intentional signals from would-be hackers who want to trigger the device.

In this case, one would need a much more complicated mechanism - possibly a challenge-response sequence where the remote must confirm that it knows a secret. (The book does not explicitly say this but, with Miles formerly in ImpSec and currently one of the several Imperial Auditors, we can assume something like this was actually employed.)

Note the difference? Against randomness, a very simple (= of low complexity) code is sufficient. It is unlikely to the extreme that I would accidentally press my Nokia cellphone's 4-digit code while carrying it in my pocket. It is practically impossible that I would manage that with an 8-digit code. If that code is entered, the phone software can safely assume I *meant* for it to happen - chance simply cannot account for that complexity. (Again, that's a 4-digit code, which is around 14 bits of information - 2^13 = 8,192 < 10,000 < 2^14 = 16,384.)

However, intelligence CAN overcome quite a hefty complexity barrier. Millions of man-years have been spent on creating ciphers that are supposed to last against other millions of man-years working to defeat them. This is VERY STRONG evidence that, given a complex system, we can safely eliminate chance as the cause. While chance can overcome complexity barriers of a few bits - even of dozens of bits, given enough time and the right circumstances - once we get in the realm of hundreds of bits (the CSI barrier) it is absolutely ridiculous to insist on claiming it is a reasonable possibility.

So - what created life, again? :D

Comments

Anonymous said…
Salut!!!!!!!!!!!

Complexitatea poate fi controlata numai prin Perfectiune! Natura a creat complexitatea extrema si a creat aparenta de simplitate deoarece a lucrat perfect.

Matei (FinalSoft!)
(Era sa fie Picosoft dar nu a fost deoarece - la acea vreme - probabil nu putea fi ceva perfect)
10:51 PM
Marcel said…
Hehe... v-ati facut firma? Mult succes daca da. Daca aveti drum prin oras, dati-mi un mail la mdpopescu@gmail.com :)
11:48 PM
Post a Comment

Popular posts from this blog

Posting dynamic Master / Detail forms with Knockout

Image
I have the following dynamic form in my GitHub Inventory project : I created the form with KnockoutJS , using some ideas from this article . The detail view looks like this: <table id="acquisition_items" class="jtable"> <thead> <tr> <th>Product Name</th> <th>Quantity</th> <th>Price</th> <th>Value</th> <th><button data-bind="click: addItem">[+]</button></th> </tr> </thead> <tbody data-bind="foreach: items"> <tr> <td> <input data-bind="value: ProductName" type="text" value="" /> </td> <td> <input data-bind="value: Quantity" type="text" value="" /> </td> <td>
Read more

Comparing Excel files, take two

Image
I already wrote this project once, on GitHub , but I can't say that I like the result. I wrote that code without TDD, mostly to see if I can still work in the "normal" fashion. I can, but I had a bug that took me a while to even discover and then was difficult to write tests for. I also hate the temporal dependency in that design (if you don't call the SortBy method first, the ExcludeRecords method will return incorrect results). Anyway; here's attempt number two, writing that code using TDD. Structure I start by creating my usual structure for projects of this type - a library for the logic, a console application for the main program and a test project for tests. I also use the Enable NuGet Package Restore option (right-click on the solution node) to add the three NuGet files that will allow someone to automatically download all the packages I'm referencing without wasting space in the source code repository. (Right now I've only added the Moq pa
Read more

EF Code First: seeding with foreign keys

This is just a quick tip, more for future reference for myself than anything else. When using Entity Framework Code First, one of the things you might want to do while developing the application is to seed your database with some test data. This can be something as easy as: protected override void Seed(InventoryDB context) { context.Products.AddOrUpdate( p => p.Name, new Product { Name = "Hammer", SalePrice = 11.99m, }, new Product { Name = "Nail Pack x100", SalePrice = 0.05m, }, new Product { Name = "Saw", SalePrice = 19.99m, }, new Product { Name = "Toolkit", SalePrice = 39.99m, } ); //... } (I am using the AddOrUpdate method so the code detects whether those products already exist and doesn't add them again if they do.) The Product class is quite simple and – most importantly – doesn't depend on any other: public class Product { public int Id { g
Read more