Skip to main content

Posts

Showing posts from December, 2011

A simple illustration of the use of goroutines and channels in Google Go

For a long time I've been meaning to spend some quality time with Google Go and I finally have the chance. For the little home project I'm working on I needed a way to generate unique IDs. In Go there's a really nice and simple way of doing this: assign a single goroutine as an ID generator and use a channel as the way to grab a new ID. Here's the code: idMaker := make(chan string) go func() { var counter int64 = 0 for { idMaker <- fmt.Sprintf("%x", counter) counter++ } } () The first line makes a channel that will be used to communicate strings. In this case, I'd decided to have unique string IDs. Then there's a go function (in this case an anonymous function) that contains a 64 bit integer counter that is incremented every time an ID is generated. When an ID is generated it is formatted as a hex number and made available on the channel. It just loops around forever providing ID

A pre-Christmas Plan 28 update

Despite the lack of public announcements from Plan 28 on the project to build Charles Babbage's Analytical Engine there's plenty going on behind the scenes. The big news is the Plan 28's registration as a charity in the UK is now complete and has been published by the Charity Commission. Plan 28 is now registered charity number 1145043 . Every charity has to have 'objects' which are a statement of its aims. Plan 28's objects are as follows: 3. Objects 3.1 The Charity's objects ("The Objects") are for the public benefit 3.1.1 The advancement of education, in particular in the fields of science and the history of science, through the construction of Charles Babbage's Analytical Engine; and 3.1.2 The advancement of science, in particular through: a) Research in the fields of computer science, engineering and mathematics; and b) The raising of public awareness of Charles Babbage's Analytical Engine

A back channel confirms that I'm right... sort of

Through a little circuitous back channel I received an unofficial follow up to a blog post about the unused machine code in the GCHQ Code Challenge part 2. The follow up assured me that the unused code was left over after some clean up was done, and that the rest of the data in the file was random filler (as I'd already heard). But as I'd already determined that it was not actually random (at least at one level) I sent a carrier pigeon out with a question about my follow up blog post. Listening for secret messages transmitted during The Archers I received a reply indicating that I had indeed 'broken' the encryption on that stream of ASCII data (by guessing the algorithm and reverse engineering the key stream), but that the underlying data was actually random ASCII generated and encrypted using the following Python code: b = ''.join([chr(randint(0x20, 0x7f)) for i in range(0, 16 * 7)]) c = codec(b, 0x1f, s=5) The first part generates 112 bytes of rando

Down the GCHQ rabbit hole (or I think there really is a part 4)

Update : Confirmation that this is correct Early this morning I blogged that I thought there was a hidden part 4 to the GCHQ Code Challenge because of the amount of non-random data in part 2. Through someone who knows someone who knows someone at GCHQ I got the response the data was "a random filler and that they ran out of time to do anything interesting". Well, I don't believe that's the whole story. There's a distinct pattern worth investigating. Firstly, here are the three blocks of data that are untouched in part 2: 0150: 7d 1f 15 60 4d 4d 52 7d 0e 27 6d 10 6d 5a 06 56 }..`MMR}.'m.mZ.V 0160: 47 14 42 0e b6 b2 b2 e6 eb b4 83 8e d7 e5 d4 d9 G.B............. 0170: c3 f0 80 95 f1 82 82 9a bd 95 a4 8d 9a 2b 30 69 .............+0i 0180: 4a 69 65 55 1c 7b 69 1c 6e 04 74 35 21 26 2f 60 JieU.{i.n.t5!&/` 0190: 03 4e 37 1e 33 54 39 e6 ba b4 a2 ad a4 c5 95 c8 .N7.3T9......... 01a0: c1 e4 8a ec e7 92 8b e8 81 f0 ad 98 a4 d0 c0 8d ............

Is there another GCHQ Code Challenge?

Update: The answer is Yes, sort of . Last week GCHQ issued a 'code challenge' as a way of attracting candidates via a web site called Can You Crack It? . I did the challenge, which actually consists of three parts and has more to do with assembly language and reverse engineering skills than cryptography (in fact, the only time you come across a cryptographic function, you can completely ignore it). The cat is completely out of the bag now because some spoilsport published complete details on the web showing how to break it, but I think there may be one more mystery worth investigating. Part 2 of the challenge involves writing a virtual machine that executes some code to decrypt an in memory buffer containing an HTTP command. Here's a dump of the memory of the virtual machine after execution: 0000: 31 04 33 aa 40 02 80 03 52 00 72 01 73 01 b2 50 1 . 3 . @ . . . R . r . s . . P 0010: 30 14 c0 01 80 00 10 10 00 00 00 00 00 00 00 00 0 . . . . . . . ........ 002