Archive for November, 2008

Right, will somebody please tell me why the toaster is trying to eat the sofa? [Nokia Home Control Centre - a disaster in waiting]

Every so often I read about a planned technology or idea and think, “wow, that really is monumentally stupid”, and this month Nokia’s new toy in development takes the prize.

Has Nokia forgot what happened when wireless access points started appearing in people’s homes? Naturally, other people started driving around and creating maps of open access points they could use. Then along came WEP, quickly followed by its subsequent and decisive departure. Personally, I still think wireless is a daft idea. Anyway, back to the point; while all the wirless abuse was/is usually pretty benign, generally limited to getting internet access for free, can you imagine what’s going to happen when the first vulnerabilities start appearing in these “Home Control Centres”? Again a totally redundant and essentially useless technology is going to wreack havock… let the games begin.

Personally, I think programming your neighbour’s livingroom lights and stereo to re-inact the “Day-O” scene from the film “Beetlejuice” could have good entertainment value. I however also think there will be a select few out there that will have other more nefarious ideas. Maybe wirelessly connecting your oven up to your new “Home Control Centre” wasn’t such a good idea afterall….

… is it just me or is there a burning smell?

UPDATED 12th April 2010: Added [] extra meaning in title.

Spam spam spam spam. Lovely spam! [Gmail spam folder advertisements]

I love it when you can determine something about the hidden internals of a system only from superficial behaviour.  For example, the idea of being able to detect the presence of a black hole from it gravitational effect on other visible objects like starts struck me as pretty neat.  Anyway, not quite as stellar, but I’ve noticed a curious Gmail phenomena: if you look into the “spam” folder, then for almost every page load, the advertisement that appears above the mail list is for some type of Spam food product (seriously, try it).

More intriguing than the sheer variety of Spam products advertised is how Google’s contextual placement is deciding to put those advertisements there.  It hasn’t come from the contents of the emails, unless I happen to be the only person on the planet receiving a load of spam mail about Spam (oh, the irony, ah-hem) – so the only possible answers must be that either its been hard-coded in (and the advertisers probably deserve a discount), or Google’s contextual system is not only basing its decisions on the content of the emails but the surrounding page structure.

I’m guessing it must be hard-coded, as I doubt any user would want to see advetisements based on the content of spam email – you really never know what it would generate.  Which means at some point they’ve tweaked those adds only to generate advertisements for products containing Spam…hehe.  Monty Python lives on.

UPDATED 12th April 2010: Added [] extra meaning in title.

Aww, p*sh! [Sgàil: trivial collision in original submission]

Sgàil, my submission to NIST’s SHA-3 competition, unfortunately has an error in it which makes finding a collision or second pre-image trivial.  The error crept in when I’d decided to change the key schedule late on from being a tree structure to a simple double block processing.

The measure which had originally protected the tree structure from block interchanges – the preliminary key – was unique for each 2048-bit block.  Unfortunately when redesigning the algorithm, I’d neglected to process a preliminary key for each 2048-bit block and instead processed a single preliminary key for each 4096-bit block.  The process where the 4096-bit block is reduced to the 2048-bit principle key uses the same preliminary key for both 2048-bit halves of the 4096-bit block, where they should have been different.  Hence the 2048-bit input pair is interchangable.

The resolution is to process a preliminary key for each 2048-bit input block and update the block counter at each 2048-bit input block rather than at each 4096-bit block.  The performance wouldn’t be significantly altered.  However since the submission deadline has now lapsed, I doubt any modifications will be accepted.

The following code generates a collision:

——-

int main() {

u8 data__a[ SGAIL__INPUT_BLOCK__SIZE * 2 ];
u8 data__b[ SGAIL__INPUT_BLOCK__SIZE * 2 ];
u8 result__a[ 64 ];
u8 result__b[ 64 ];

memset( data__a, 0, SGAIL__INPUT_BLOCK__SIZE * 2 );
memset( data__b, 0, SGAIL__INPUT_BLOCK__SIZE * 2 );

data__a[ 0 ] = 1;
data__a[ 256 ] = 2;

data__b[ 0 ] = 2;
data__b[ 256 ] = 1;

Hash( 512, data__a, ( SGAIL__INPUT_BLOCK__SIZE * 2 ) * 8, result__a );
Hash( 512, data__b, ( SGAIL__INPUT_BLOCK__SIZE * 2 ) * 8, result__b );

do__display_512_bit_hash__byte_wise( result__a );
do__display_512_bit_hash__byte_wise( result__b );

}
——–

I will post a revision of Sgàil in the next few days with the error fixed, although I don’t know of its applicability as concerns the SHA-3 competition.

UPDATED 21st November 2008: Ok, maybe a bit more than a few days, keep getting side-tracked. Will upload new revision once have fixed the specification document.

UPDATED 21st January 2009: Version 0.4 has been released here which corrects this error…. enjoy ;-)

UPDATED 12th April 2010: Added [] extra meaning in title.

Its good to talk. [Comment moderation removed]

I’ve removed the need to wait for comment moderation, so post away.

UPDATED 7th November 2008: The Akismet spam filter seems to be a tad on the aggressive side, so if your comment doesn’t appear immediately, it will appear soon as I periodically check the queue.

UPDATED 12th April 2010: Added [] extra meaning in title.

First Blood in SHA-3 Competition. ['WaMM' submission has collision]

NIST hasn’t even published the complete and proper candidates, but there’s already a full break (second pre-image) of one of the candidate hash algorithms in the SHA-3 competition, pretty exciting, huh?  The “WaMM” hash algorithm is the first to fall, see here for more info.  There’s also been an attack on another of the submissions, EnRUPT.  A list of some (I say some, there’s quite a lot on the list) of the candidates can be found at the SHA-3 zoo.

In this type of process, such a complete break so early on is certainly a good indicator that the process is working as intended – and getting good involvement.  It also serves as a stark warning to those who would use a home-grown crypto scheme in a commercial product without full peer-review of their algorithm, the consequences of which are no less apparent than the failure of the ubiqutous Mifare classic, used for example in the Oyster card in London.

UPDATED 12th April 2010: Added [] extra meaning in title.