One of the main principals of a crypto message is that it can't be reversed, and no part of the enciphered message should be able to be able to be guessed without the secret key. As shown in this (https://appliance.cloudshark.org/blog/packet-capture-of-heartbleed-in-action/) post about heartbleed, we can tell what heartbeat message type was chosen, but we can't identify how many bytes the payload was unless we decrypt the data. So my question is, without having man in the middled all the sessions, or had the decryption keys. How are these researchers making this statement? The issue line was: buffer = OPENSSL_malloc(1 + 2 + payload + padding); How can they differentiate between payload/padding after it's been sent across the wire?

I'm a big fan of the Head First series and I recently used the Head First C# book to learn. It's great but requires a Windows OS/VM to use so maybe not the best for you. The upside is it's centered around building games, which would greatly interest a kid. I've been eyeing the Head First Java book for a while now, and for your purpose I just pulled up a comment from the headfirst site: "My thirteen year old son who is new to programming started writing Java programs after reading this book.He had so much fun writing a battleship game after reading this book!"

I'm a fan of Where's James. It's free, has motion detection, works with night vision cameras, etc. Just plug in a good webcam and your good to go. It can upload to FTP incase they lift your security system. It's neat.

At Defcon this year an instructor in computer forensics for law enforcement gave a very interesting talk on how they remotely exploit machines, mount drives read only, and copy hard disks off for analysis, without warrents. This is obviously the US side but the UK could be similar: http://www.youtube.com/watch?v=PTYYlHYBF0Q

I was just logging in to challenge that all 228 people a) believed in souls and b) that (if souls exist) all 228 people had one.

I like the Openfire server with Spark client myself.