Ben Laurie - Cod Chowder
Chowder isn’t exactly rocket science, but this went pretty well, so documenting it here…
I actually made this almost entirely from frozen ingredients and it was just fine. Fresh might be better.
Finely chopped leek
Smoked bacon, sliced (I used some lardons I had in the freezer)
Cubed potatoes
Chicken stock (maybe fish stock would be better, I didn’t have any) or water
Milk (about half as much as stock)
Pepper
Mace
Cod
King prawns
Sweetcorn
Cream
Fry the leeks and bacon in a little butter/olive oil (I used both) until pretty soft – I didn’t crisp the bacon for a change. I think it is better for chowder not to. Add cubed potatoes and fry for a bit longer, then add chicken stock (or water or fish stock) and bring to the boil. Simmer until the potatoes have softened, then zap half the mixture with a blender (I just did this in situ). Season (I didn’t need salt, there was enough in the bacon). Add milk, fish, prawns and bring back up to a simmer, cook for a few minutes, making sure the fish falls apart. Add cooked sweetcorn and bring back up to temperature. Finally, add some cream.
Quantities should be chosen so that the final result is good and thick.
Serve with warm, crusty bread and butter. Works as a whole meal.
Ben Laurie - It’s All About Blame
I do not represent my employer in this post.
“The only way to manage this is true transparency and no anonymity. In a world of asynchronous threats, it is too dangerous for there not to be some way to identify you. We need a [verified] name service for people. Governments will demand it.”
I don’t care whether he actually said it, but it neatly illustrates my point. The trouble with allowing policy makers, CEOs and journalists define technical solutions is that their ability to do so is constrained by their limited understanding of the available technologies. At Google (who I emphatically do not represent in this post), we have this idea that engineers should design the systems they work on. I approve of this idea, so, speaking as a practising engineer in the field of blame (also known as security), I contend that what Eric really should have allegedly said was that the only way to manage this is true ability to blame. When something goes wrong, we should be able to track down the culprit. Governments will demand it.
Imagine if, the next time you got on a plane, instead of showing your passport, you instead handed over an envelope with a fancy seal on it, containing your ID, with windows showing just enough to get you on the plane (e.g. your ticket number and photo). The envelope could be opened on the order of a competent court, should it turn out you did something naughty whilst travelling, but otherwise you would remain unidentified. Would this not achieve the true aim that Eric allegedly thinks should be solved by universal identification? And is it not, when spread to everything, a better answer?
Of course, in the physical world this is actually quite hard to pull off, tamper-proof and -evident seals being what they are (i.e. crap), but in the electronic world we can actually do it. We have the crypto.
Just sayin’.
Ben Laurie - FreeBSD Capsicum
I mentioned FreeBSD Capsicum in my roundup of capability OSes earlier this year without mentioning that I am involved in the project. Since then we’ve managed to port and sandbox Chromium, using less code than any other Chromium sandbox (100 lines), as well as a number of other applications. Also impressive, I think, is the fact that Robert Watson managed to write this sandbox in just two days, having never seen the Chromium codebase before – this is as much a testament to Robert’s coding skills and the clean Chromium codebase as it is to Capsicum, but nevertheless worth a mention.
Anyway, at USENIX Security this week, we won Best Student Paper. A PC member described the paper to me as “excellent” and “very important”. Robert has also blogged about it rather more eloquently than I can manage at this time in the morning.
You can read the paper, too, if you want.
Even more exciting, FreeBSD 9 will include the Capsicum capability framework, allowing the peaceful coexistence of capability and POSIX programs. Although this has been attempted before, as far as I am aware all previous versions have put a POSIX emulation layer on top of a capability system, rather than grafting capabilities onto POSIX. Since Capsicum is highly efficient and FreeBSD is a perfectly sound and portable system (and my server OS of choice), this opens up the possibility of a gradual migration to capabilities, something that has been problem up to now.
Robert and I (and a host of others) are continuing our research into practical capability systems, Robert at Cambridge and me at Google. Work is also in progress to port Capsicum to Linux.
Ben Laurie - Alternatives to Adium?
When I’m at home, I tend to use Pidgin for IM. When travelling, I generally use Adium. But Adium is driving me nuts: basically it is fantastically unstable. Empirically this appears to be related to the number of contacts, of which I have many (i.e. reducing the number makes it less crashy).
So … what can I use on MacOS that’s less crap than Adium but still supports OTR?
Ben Laurie - Cabbage and Peas
I have a vague recollection of being served this somewhere, but I can’t remember where.
Smoked bacon
Cabbage (we used sweetheart, but I don’t think it is critical, savoy would probably be even nicer)
Frozen peas
Double cream
Slice the bacon thinly, fry in a little oil until crispy (at least, that’s what I’d do, my sous-chef decided to stop sooner than that and it was fine), chop cabbage into strips, add to the bacon+fat and braise (I found I didn’t need a lid at all, but you may – and even may need to add a little water, depending on the cabbage). When the cabbage is nearly done, add the frozen peas. As soon as they defrost, a generous gloop of double cream. Add salt at some point if the bacon isn’t too salty and pepper in any case.
We ate this with roast pork belly and roast potatoes. Yummy.
Ben Laurie - Nigori Update
It’s been a while (I’ve been busy on another project, more on that soon, I hope), but finally…
I’ve updated the protocol slightly to correct a subtle bug in the secret splitting specification. You can find the latest versions and diffs here.
I’ve also finally got around to tidying the code up some (though there’s still plenty more to do), you can find an appspot server, a command line client and various libraries, all in Python, at nigori.googlecode.com. As always, patches are welcome!
The code does not fully reflect the draft protocol yet – in particular, it still uses a Schnorr signature where the draft calls for DSA.
If you want to play with the command-line client, I already have a server running on appspot. Here’s how … from the client directory, run
Not the most elegant interface in the world. Note that the server is experimental, I may break it, delete all the data, etc. Of course, you can run your own.
Note also that the whole protocol is experimental at this point, I wouldn’t rely on it to store your vital passwords just yet!
Ben Laurie - FreeBMD Seeks An Executive Director
I don’t often mention the FreeBMD project on this blog, perhaps I should. Anyway, we (the trustees of FreeBMD) have decided that it’s time to hire an Executive Director. It occurred to me that some of my readers might be interested, or might know someone who is.
Ben Laurie - TLS Renegotiation, 7 Months On
It’s been 7 months since the TLS renegotiation problem went public and Opera’s security group have a couple of interesting articles about it. The first is about adoption of patched versions and the verdict is not good, as this graph shows…
At this rate it will be two years before the fix is widely adopted!
The second is about version intolerance – scarily, nearly 90% of patched servers will not work when a future version of TLS bumps the major version number to 4 (it is currently 3). This is pretty astonishingly crap, and is likely to cause us problems in the future, so I’m glad the Opera guys are working hard to track down the culprits.
By the way, at least according to Opera, OpenSSL does not have this problem.
Ben Laurie - XAuth: Who Should Know What?
Note that I am not speaking for my employer in this post.
I’ve been following the debate around XAuth with interest. Whilst the debate about whether centralisation is an acceptable stepping stone to an in-browser service is interesting, I am concerned about the functionality of either solution.
As it stands, XAuth reveals to each relying party all of my identity providers, so that it can then present UI to allow me to choose one of them to authenticate to the RP. Why? What business of the RP is it where I have accounts? All that should be revealed is the IdP I choose to reveal (if any). This seems easy enough to accomplish, even in the existing centralised version: all that has to happen is for the script that xauth.org serves is to include the UI for IdP choice.
This is not just privacy religion (or theatre): as the EFF vividly illustrated with their Panopticlick experiment, it is surprisingly easy to uniquely identify people from signals you would have thought were not at all identifying, such as browser version and configuration information. Indeed, a mere 33 IdPs would provide enough information (if evenly distributed) to uniquely identify every person in the world. Meebo had no difficulty at all coming up with 15 of them for page one of many in their introductory blog post…
Ben Laurie - Nigori: Protocol Details
As promised, here are the details of the Nigori protocol (text version). I intend to publish libraries in (at least) C and Python. At some point, I’ll do a Stupid version, too.
Comments welcome, of course, and I should note that some details are likely to change as we get experience with implementation.
Ben Laurie - Nigori: Storing Secrets in the Cloud
Lately, I’ve been thinking about phishing. Again. If we want users to take our sensible advice and use different passwords everywhere, then they’ve got to be able to remember those passwords and move them from machine to machine. In order to do that with any ease, we’ve got to store them in the cloud. But the question is, how to do that securely?
So, that’s what I’ve been working on for a while, and the result is Nigori, a protocol and open source implementation for storing secrets in the cloud. It doesn’t require you to trust anyone (other than your completely insecure client, of course … I’m working on that, too). The storage server(s) are incapable of getting hold of the keying material, and if you want you can use splits to ensure that individual servers can’t even attack the encrypted secrets.
Of course, Nigori isn’t just for passwords, you could also use it to store private keys and the like. For example, Salmon can use it to store signing keys.
The source is in a bit of a state right now, following some hack’n’slay related to appspot’s crypto … oddities, but I’ll post about that soon. For now, in case you missed it above, here’s an overview document.
Ben Laurie - Programming Languages
I don’t often go in for the reblogging thing, but this made me laugh out loud in several places. For example:
1986 – Brad Cox and Tom Love create Objective-C, announcing “this language has all the memory safety of C combined with all the blazing speed of Smalltalk.” Modern historians suspect the two were dyslexic.
Ben Laurie - Wikileaks: The Facts
Apparently some reporters think it’s useful to make stupid claims about Wikileaks. I won’t bother to link, but just in case you mistook them for journalism: for the record, I am a member of Wikileaks’ advisory board and I am honoured to be. I don’t think Julian Assange is crazy, I think he’s a very talented guy. Yeah, he’s a little unusual, but that just adds to the fun. It is true, however, that I don’t know anything about how Wikileaks operates in detail and it is also true that I think that’s a good idea.
If you don’t know what I’m talking about, I hear there’s a search engine that might help. Or you could do something useful with your time.
Ben Laurie - Stir-fried Trout and Almond
My son complained that he didn’t like fish and to compensate he demanded we stir-fry it. Here’s what I invented…
Trout fillets, with skin (I think we used river trout)
Ginger
Spring onions
Dark soy
Sugar
Cornflour
Almonds
Cut the trout fillets into strips about 1/2″ wide. Marinade in dark soy, finely chopped ginger and spring onions and a little sugar. While it is marinading stir-fry the almonds (a little oil and a very low heat works best, don’t pause or they burn and burnt nut is very bitter). Remove the almonds, add some cornflour to the marinade, then get a little oil smoking hot. Cook the strips of trout, salvaged one at a time from the marinade, for a couple of minutes a side. Do them in batches so they crisp up nicely (especially the skin side). Once they’re all done, quickly stir fry them with the almonds and a little more soy. I resisted the temptation to throw the extra marinade into the dish at this point. Turn off the heat, mix in yet more finely chopped spring onion and a little sesame oil. As usual, no quantities, but I recommend a _lot_ of spring onions, use about half in the marinade and half at the end (I used 10 spring onions for 6 trout fillets).
Serve with rice, of course, and a vegetable (I did leeks).
Ben Laurie - Capability Operating Systems
Now that we’ve deployed the most successful capability language ever, it’s time to start thinking about the rest of the stack, and one end of that stack is the operating system.
Luckily, thinking in this area has been going on a long time – indeed, capabilities were invented in the context of the OS, though for a long time were thought to be the exclusive domain of specialised hardware. Some of that hardware ended up being extremely widely deployed, too, so don’t think this is the stuff of lab experiments only. Sadly, though, despite the hardware supported capabilities, these were not generally exposed up to the level of the kernel/userland interface; they were thought to be useful only within the kernel (with one notable, but not very well known or widely used, exception),
However, more recently it has been realised that capabilities are not only useful in userland, but also can be implemented on top of commodity hardware, resulting in a crop of new capability operating systems. But these still suffer from the problems that traditional capability languages have suffered from: they need the world to be completely reinvented before you can use them. Because the capability paradigm is fundamentally different from the ambient authority ACL-based world we live in, no existing software can fully enjoy the benefits of capabilities without at least some rewriting.
So, the interesting research question has now become: how can we move toward this world without having to rewrite everything on day one? Some progress has been made with mapping POSIX onto capabilities. Heading in a completely different direction is the idea of running existing OSes as guests on a capability system. Yet another approach is to apply capabilities to more restricted domains: one that I have been involved in is the idea of hosting untrusted software “in the cloud”, in the same vein as Google App Engine. Because this software is all new, changing the way it has to work is not a big deal.
But the thing that interests me most is the work being done on FreeBSD, which allows capability-based code to coexist with (or even be contained within) existing POSIX code. This provides a genuine, believably workable, migration path from existing systems to a brave new capability world. We can move one application (or even one library) at a time, without breaking anything. Which is why I am pleased to be able to say I am involved in this work, too. What’s even better is this work is by no means specific to FreeBSD – the same principles could be applied to any POSIX system (so Linux and Mac OS X would be good targets). Just as we have seen success with Caja it seems to me that this route can deliver success at the OS level, because it allows a gradual, piecemeal migration.
Unusually for me, I have not interrupted my narrative flow by naming or saying too much directly about the various things I link to – however, I appreciate that following links in the middle of reading can get distracting, so here are many of the links again with some explanation…
Caja: a capability version of Javascript. I have written about it before.
CAP computer: the project that invented capabilities.
IBM System/38: more capability hardware.
AS/400: derived from the System/38. Although this had capabilities, they were not exposed to userland. Very widely used commercially.
KeyKOS: a commercial capability operating system.
Amoeba: an experimental capability system – like Caja, it tends to advertise its other virtues rather than describing itself as a capability system.
EROS: another experimental capability OS – originally intended to provide robustness, not security. The first to run on a standard PC.
CapROS: when EROS was discontinued, it lived on as CapROS. Google has recently sponsored the development of a web-hosting experiment on top of CapROS.
Coyotos: by the original designer of EROS. Now also discontinued (can you spot a trend here?).
Plash: the Principle of Least Authority Shell. This shell runs on Linux, figures out from the command line what any particular invocation of an executable should have access to, creates a sandbox with access to only those things, then maps POSIX calls onto the sandboxed things.
L4: a modern capability-based microkernel.
L4Linux: Linux running on top of L4. Although this is nice for things like driver isolation, it seems like the wrong direction because it does not assist with exposing capabilities to userland.
FreeBSD Capsicum: a capability mode for FreeBSD. Whole executables can opt in to this mode, coexisting with POSIX binaries. Even more interestingly, libraries can spawn off capability-mode subprocesses whilst effectively remaining in POSIX mode themselves. This allows the transparent implementation of privilege separation. This project has also been sponsored by Google.
Ben Laurie - Caja on Orkut
If you’ve been living in a box for the last couple of years, you might not know that Caja is an open source project I am involved in at Google to make the web safer. Specifically, it allows untrusted Javascript, HTML and CSS to be sandboxed in a very fine-grained way. For example, the untrusted content can be limited to a subset of the whole DOM, primordial objects can be replaced or removed, properties of objects can be protected (from read, write or execution) and any method can be removed, replaced or attenuated. Yet it is still possible to write fully-featured Javascript applications in Caja. And, as a bonus, Caja hides the differences between browsers – any code you write will Just Work on any supported browser.
Caja has long been used by Yahoo!, ironically, to protect users from malicious gadgets on their Application Platform but until recently has been a bit of a poor relative at Google. So, I’m pleased to report that it is now in use to protect Orkut users.
Because Caja is open source, we don’t necessarily find out when people use it: do you know of someone using Caja? Leave a comment!
Ben Laurie - Selective Disclosure, At Last?
Apparently it’s nearly five years since I first wrote about this and now it finally seems we might get to use selective disclosure.
I’m not going to re-iterate what selective disclosure is good for and apparently my friend Ben Hyde has spared me from the need to be cynical, though I think (I am not a lawyer!) he is wrong: the OSP applies to each individual specification – you are not required to use them in the context of each other.
So, for now, I will just celebrate the fact that Microsoft has finally made good on its promise to open up the technology, including BSD-licensed code. Though I guess I will have to inject one note of cynicism: a quick glance at the specification (you can get it here) suggests that they have only opened up the most basic use of the technology: the ability to assert a subset of the signed claims. There’s a lot more there. I hope they plan to open that up, too (how long will we have to wait, though?).
ShmooCon News - ShmooCon 2010 Videos
Videos from this year's conference are now online. We're still missing a few speaker slides - we'll try to have those posted by the end of the week.Ben Laurie - Trust and Vulnerability
Ed Felten has a nice post about the crazy idea that someone can decide for us which CAs are trusted. He correctly points out that we conflate two meanings of the word “trust”, but then proposes to fix it by using the word slightly differently, for example:
“CNNIC is a trusted certificate authority.”
versus
“Everyone trusts CNNIC to be a certificate authority.”
I’ve long advocated instead saying “is vulnerable to”, which makes it much clearer what is going on, so I would say “CNNIC is a certificate authority everyone is vulnerable to”. “Trusted third party” would become “Third party you are vulnerable to” and so on. Kinda clunky, but you know where you stand.
A historical note: I believe I came up with this in one of my very first conversations with Jon Shapiro and Mark Miller about the nature of “trust” in distributed computer systems – a word that really should not be used at all in that context, I believe.
Ben Laurie - Broccoli and Tomato Stirfry
I’ve been using little tomatoes a lot lately, I have no idea why I’ve traditionally neglected them, they’re rather nice. Last night I needed some vegetables to go with some Thai fishcakes, and I invented this…
Tenderstem broccoli (or purple sprouting broccoli – not a big fan of the traditional big kind, too mushy)
Cherry tomatoes
Ginger
Light soy
Groundnut oil
Spring onions
Get the oil smoking hot, add thinly sliced ginger (I like my ginger in chunks big enough to eat, but feel free to dice it) stirfry for a few seconds, then add the broccoli (I usually halve each stem), stirfy that for a couple of minutes, then throw in cherry tomatoes sliced in half – I did about twice as much broccoli as tomatoes. When they have gone fairly mushy, add a good dose of light soy and stirfry for another 30 seconds or so. Turn off the heat and then add thinly sliced spring onions. The broccoli should be fairly firm, but edible 
I also like to chuck some sesame oil on things like this, after the spring onions, but I guess its optional.
Ben Laurie - Stupid Mailing List
It seems Stupid just won’t go away – Ben Clifford and I have been gradually expanding it – it now has functions and even primitive I/O. I’m working on a new test harness and we have regular discussions on language philosophy. So I figured it was time for a mailing list for developers (and other interested parties). Here it is.
ShmooCon News - Thanks and Updates
Well, the snow didn't seem to stop us one bit. Thanks so much to everyone who braved the weather and spent the weekend with us. As reported in the 0wn the Con session, we had roughly 1340 people show up out of the expected 1550. Not bad considering the obstacles faced in getting to the DC area during a record snowfall. ShmooCon attendees are hardcore!A number of you were with us virtually via the ustream feed. Yes, there were a few hiccups here and there but we learned a lot and we'll definitely be doing it again next year. If you missed those, rest assured that we're actively working to get the videos of the talks up and online. We'll make an announcement here when we're finished.
What else?
Final donation amounts for T-Shirt Charities are as follows:
- Hackers for Charity - $3324
- EFF - $2704
- American Red Cross - $2284
We've got a few Lost and Found items to report. If you think one of these items is yours send identifying information to info@shmoocon.org:
- A blue SRA Bag with items inside
- A camera
- A phone
- A black Nokia bag with items inside
That's it for now. More to come soon.
Ben Laurie - Perhaps Not So Stupid, After All?
Stupid now generates correct (single-block, still) SHA-256 code in C. It has functions. We’re starting to wonder about adding structures, and the semantics of arrays – particularly whether an array passed for output can also be used for input (or vice versa). I’m inclining towards making that illegal – if you want a function that, say, fills in every second entry in an array, then you’d need to pass in the array to be filled in, and return a second array which would be the result. The function would have to copy the input array to the output before filling in the new values (or copy the parts it isn’t going to fill in). It seems to me this makes analysis simpler, but can easily be optimised by smart compilers, too.
I guess its time we started writing some of this down! I’d also like to add generators for some common scripting languages, like Perl, Python and PHP.
The thing I’m a little scared of is that eventually, if I’m going to take this seriously, we’re going to need a bignum implementation – not too hard to do if you don’t care about efficiency, I guess.
ShmooCon News - Just to be clear
Shmoocon is like the postal service. Come rain, come snow, come sleet - we will deliver. The con will go on as planned.ShmooCon News - ShmooCon Live Streaming Video
We're still on track to do the live streaming during the con. You will be able to watch at:https://www.shmoocon.org/video.html
Nothing to see there yet, but now you know. We'll post an update on Friday.
ShmooCon News - Oh the Weather Outside....
is potentially going to be snowy come ShmooCon weekend. Just a friendly reminder folks - check the forecast before traveling.Ben Laurie - Writing Compilers Quickly
How did you bring up a compiler so quickly – what environment, what development system is the compiler written in?
Firstly, I’ve had a lot of practice – I’ve been writing (small) compilers for at least 20 years now. I’ve been writing code for over 35 years. That helps. But to talk about the reproducible parts of what I did…
Firstly, I wrote the compiler in Perl. I like Perl for quick hacks, and I also like to write Perl code “properly” – that is, I use modules and object oriented programming, not great monolithic blocks of Perl gibberish.
Secondly, I used a compiler-compiler, in this case, Parse::Yapp. This uses a specification language rather like BNF, and exactly like its predecessors, yacc and bison, so there was zero learning curve for me there.
I do remember finding yacc extremely puzzling when I first started with it, so if you are new to this, I would highly recommend Antlr and Antlrworks. The only reason I did not use Antlr is its Perl support seems to be pretty experimental, and I didn’t want to spend time fighting the tools. Otherwise, Antlr is vastly superior to the whole yacc/bison/yapp thing. Antlrworks lets you interactively explore your parsing, complete with diagrams. It really is quite awesome and I love it.
Thirdly, I avoided using a lexer generator. In my experience, these are fiddly and more trouble than they’re worth, especially if you’re writing in Perl, where you have very nice pattern matching tools that allow you to write a lexer in not many lines of code (about 60 in the current version of Stupid).
Fourthly, I used monkey-patching to inject the language-dependent output part of the code. I’ve never really (consciously) used this technique before – I first came across it as a formal notion when we were wrestling with early versions of Caja, as it is very widely used in Javascript libraries. Although it is kinda evil and caused us untold pain with Caja, it does make for a very nice separation between components.
Fifthly, I kept the grammar of Stupid simple – I make life harder for the programmer in order to make the parser simpler. This is for two reasons, firstly, I was in a hurry, but more importantly, it is a design aim of Stupid that it should be clear to the programmer exactly what is happening. Getting clever with the grammar does not aid that process.
Sixthly, keeping your head clear is good! Parsers naturally produce parse trees with great ease, so building a parse tree and then later processing that is the way to go. Trying to do it all in one go rarely works well (single pass compilers are generally rather limited, though Stupid is technically mostly single pass at the moment). Getting used to recursion helps with processing parse trees.
Finally, I had a previous project, CaPerl, where I’d used Parse::Yapp, so I could crib from that to get off the ground rapidly.
As for the rest of the environment: FreeBSD for the operating system, emacs for the editor (wish there were a yapp/yacc mode – and even better, a Stupid mode!), Mercurial for version control.
Ben Laurie - Stupid Haskell, Google Code
I can see the amusement I can derive from Stupid is going to be endless. If somewhat stupid.
More seriously, Ben Clifford wrote a Haskell plugin for Stupid. So, with his permission, I have added it to the source. I’ve also created a Google Code site for it – sadly someone already has stupid.googlecode.com, so you’ll find it at stupid-crypto.googlecode.com.
Ben also added a lot of test cases, which I haven’t yet pulled in because I want to move them into their own directory, but they may be there by the time you check the code out.
I still haven’t got around to testing the SHA-256 implementation, either. One day! Oh, and it seems the Haskell breaks, which may well be my fault. But I don’t really understand Haskell, so I might find it hard to fix.
Ben Laurie - Verified by Visa, Again
Not exactly news, but those clever chaps at Cambridge have a nice writeup of the problems in Verified by Visa and MasterCard SecureCode. Short, too. Worth a read.
Ben Laurie - Stupid: A Metalanguage For Cryptography
Various threads lately have got me thinking about implementing cryptography and cryptographic protocols. As I have mentioned before, this is hard. But obviously the task itself is the same every time, by its very nature – if I want to interoperate with others, then I must implement effectively the same algorithm as them. So why do we ever implement anything more than once? There are various reasons, varying as to their level of bogosity. Here’s a few
- Trust: “I don’t want to trust anyone else’s code”. This, in my view is mostly bogus. If you don’t trust others to write your crypto, then you’ve got some pretty big problems on your hands…
- You’re likely to be using some pretty heavyweight stuff like SSL and/or X.509, and reimplementing those is a seriously major job. Are you really going to do that?
- Unless you are also a cryptographer, then you’re trusting the guys that designed the crypto you’re implementing anyway.
- Ditto protocol desginer.
- Languages: an implementation in Java isn’t going to work so well in Python. And although its true that you can plug C implementations into almost everything, there are legitimate and not-so-legitimate reasons for not wanting to do so…
- You don’t trust native code: see above.
- It makes your distribution hard to build and/or use and tricky to install.
- You are running on a platform that doesn’t allow native code, for example, a web hosting company, or Google’s App Engine.
- Native code has buffer overflows and MyFavouriteLanguage doesn’t: true, but probably the least of your worries, given all the other things that you can get wrong, at least if the native code is widely used and well tested.
- Efficiency: you are not in the long tail of users who’s transactions per second is measured in fractions. In this case, you may well want specialised implementations that exploit every ounce of power in your platform.
Of these, reimplementation for efficiency clearly needs a completely hand-crafted effort. Trust issues are, in my view, largely bogus, but if you really want to go that way, be my guest. So what does that leave? People who want it in their chosen language, are quite happy to have someone else implement it and are not in need of the most efficient implementation ever. However, they would like correctness!
This line of thinking let me spend the weekend implementing a prototype of a language I call “Stupid”. The idea is to create a language that will permit the details of cryptography and cryptographic protocols to be specified unambiguously, down to the bits and bytes, and then compile that language into the language of your choice. Because we want absolute clarity, Stupid does not want to be like advanced languages, like OCaml and Haskell, or even C, where there’s all sorts of implicit type conversions and undefined behaviour going on – it wants it to be crystal clear to the programmer (or reviewer) exactly what is happening at every stage. This also aids the process of compiling into the target language, of course. So, the size of everything wants to be measured in bits, not vague things like “long” or “size_t”. Bits need to be in known places (for example, big-endian). Operations need to take known inputs and produce known outputs. Sign extension and the like do not want to happen magically. Overflow and underflow should be errors, unless you specifically stated that they were not, and so on.
To that end, I wrote just enough compiler to take as input a strawman Stupid grammar sufficient to do SHA-256, and produce various languages as output, in order to get a feel for what such a language might look like, and how hard it would be to implement.
The result is: you can do something rough in a weekend
Very rough – but it seems clear to me that proceeding down this road with more care would be very useful indeed. We could write all the cryptographic primitives in Stupid, write relatively simple language plugins for each target language and we’d have substantially improved the crypto world. So, without further ado, what does my proto-Stupid look like? Well, here’s SHA-256, slightly simplified (it only processes one block, I was going cross-eyed before I got round to multiple blocks). Note, I haven’t tested this yet, but I am confident that it implements (or can be easily extended to implement) everything needed to make it work – and the C output the first language plugin produces builds just fine with gcc -Wall -Werror. I will test it soon, and generate another language, just to prove the point. In case the code makes your eyes glaze over, see below for some comments on it…
"This code adapted from Wikipedia pseudocode";
"Note 2: All constants in this pseudo code are in big endian";
"Initialize variables";
"(first 32 bits of the fractional parts of the square roots of the first 8 primes 2..19):";
uint32 h0 = 0x6a09e667;
uint32 h1 = 0xbb67ae85;
uint32 h2 = 0x3c6ef372;
uint32 h3 = 0xa54ff53a;
uint32 h4 = 0x510e527f;
uint32 h5 = 0x9b05688c;
uint32 h6 = 0x1f83d9ab;
uint32 h7 = 0x5be0cd19;
"Initialize table of round constants";
"(first 32 bits of the fractional parts of the cube roots of the first 64 primes 2..311):";
array(uint32, 64) k =
(0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5,
0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5,
0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3,
0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174,
0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc,
0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da,
0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7,
0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967,
0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13,
0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3,
0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070,
0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5,
0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3,
0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208,
0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2);
"For now, dummy in the message instead of declaring a function wrapper";
"Also, for now, allow enough room in the input for padding, etc, to simplify the loop";
uint32 message_bits = 123;
array(uint8, 64) message =
(0x12, 0x34, 0x56, 0x78, 0x9a, 0xbc, 0xde, 0xf0,
0x0f, 0xed, 0xcb, 0xa9, 0x87, 0x65, 0x43, 0x21);
uint32 pad_byte = 0;
uint32 pad_bit = 0;
uint32 tmp = 0;
uint32 tmp2 = 0;
array(uint32, 16) w = (0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
uint32 i = 0;
uint32 s0 = 0;
uint32 s1 = 0;
uint32 a = 0;
uint32 b = 0;
uint32 c = 0;
uint32 d = 0;
uint32 e = 0;
uint32 f = 0;
uint32 g = 0;
uint32 h = 0;
uint32 maj = 0;
uint32 t1 = 0;
uint32 t2 = 0;
uint32 ch = 0;
"Pre-processing:";
"append the bit '1' to the message";
"note that we're using a 32-bit length for now";
"all the op32, op8 etc are _without_ wrap (where applicable) - i.e. wrap is an error";
"they also require left and right to both be the correct type and size";
"also, we have no precedence, it is up to you to bracket things";
"rshift is with zero padding";
pad_bit = 7 minus32 (message_bits mod32 8);
pad_byte = (message_bits plus32 1) rshift32 8;
message[pad_byte] = message[pad_byte] or8 (1 lshift8 pad_bit);
"append k bits '0', where k is the minimum number >= 0 such that the
resulting message length (in bits) is congruent to 448 (mod 512)";
"eq32 and friends return a boolean value (which is not even a bit)";
if (pad_bit eq32 0) {
pad_bit = 7;
pad_byte = pad_byte plus32 1;
} else {
pad_bit = pad_bit minus32 1;
}
"bor is like C || (i.e. RHS is only executed if LHS is false)";
"448/8 = 56";
while (((pad_byte mod32 512) ne32 56) bor (pad_bit ne32 7)) {
message[pad_byte] = message[pad_byte] and8 (not8 (1 lshift8 pad_bit));
if (pad_bit eq32 0) {
pad_bit = 7;
pad_byte = pad_byte plus32 1;
} else {
pad_bit = pad_bit minus32 1;
}
}
"append length of message (before pre-processing), in bits, as 64-bit big-endian integer";
message[pad_byte] = 0;
message[pad_byte plus32 1] = 0;
message[pad_byte plus32 2] = 0;
message[pad_byte plus32 3] = 0;
message[pad_byte plus32 7] = mask32to8 message_bits;
tmp = message_bits rshift32 8;
message[pad_byte plus32 6] = mask32to8 message_bits;
tmp = message_bits rshift32 8;
message[pad_byte plus32 5] = mask32to8 message_bits;
tmp = message_bits rshift32 8;
message[pad_byte plus32 4] = mask32to8 message_bits;
"for each chunk (we only have one, so don't bother with the loop for now)";
" break chunk into sixteen 32-bit big-endian words w[0..15]";
tmp = 0;
while(tmp ne32 16) {
tmp2 = tmp lshift32 2;
w[tmp] = ((widen8to32 message[tmp2]) lshift32 24)
plus32 ((widen8to32 message[tmp2 plus32 1]) lshift32 16)
plus32 ((widen8to32 message[tmp2 plus32 2]) lshift32 
plus32 (widen8to32 message[tmp2 plus32 3]);
tmp = tmp plus32 1;
}
" Extend the sixteen 32-bit words into sixty-four 32-bit words";
i = 16;
while(i ne32 64) {
s0 = (w[i minus32 15] rrotate32 7) xor32 (w[i minus32 15] rrotate32 18) xor32 (w[i minus32 15] rshift32 3);
s1 = (w[i minus32 2] rrotate32 17) xor32 (w[i minus32 2] rrotate32 19) xor32 (w[i minus32 2] rshift32 10);
w[i] = w[i minus32 16] plus32 s0 plus32 w[i minus32 7] plus32 s1;
}
" Initialize hash value for this chunk:";
a = h0;
b = h1;
c = h2;
d = h3;
e = h4;
f = h5;
g = h6;
h = h7;
" Main loop:";
i = 0;
while(i ne32 64) {
s0 = (a rrotate32 2) xor32 (a rrotate32 13) xor32 (a rrotate32 22);
maj = (a and32 b) xor32 (a and32 c) xor32 (b and32 c);
t2 = s0 plus32 maj;
s1 = (e rrotate32 6) xor32 (e rrotate32 11) xor32 (e rrotate32 25);
ch = (e and32 f) xor32 ((not32 e) and32 g);
t1 = h plus32 s1 plus32 ch plus32 k[i] plus32 w[i];
h = g;
g = f;
f = e;
e = d plus32 t1;
d = c;
c = b;
b = a;
a = t1 plus32 t2;
}
" Add this chunk's hash to result so far:";
h0 = h0 plus32 a;
h1 = h1 plus32 b;
h2 = h2 plus32 c;
h3 = h3 plus32 d;
h4 = h4 plus32 e;
h5 = h5 plus32 f;
h6 = h6 plus32 g;
h7 = h7 plus32 h;
"end of outer loop (when we do it)";
"Obviously I can also do this part, but right now I am going cross-eyed";
"Produce the final hash value (big-endian):
digest = hash = h0 append h1 append h2 append h3 append h4 append h5 append h6 append h7";
Notice that every operator specifies the input and output sizes. For example plus32 means add two 32-bit numbers to get a 32-bit result, with wrap being an error (this probably means, by the way, that the last few plus32s should be plus32_with_overflow, since SHA-256 actually expects overflow for these operations). So far we only deal with unsigned quantities; some “overflows” are actually expected when dealing with negative numbers, so that would have to be specified differently. Also, I didn’t deal with the size of constants, because I wasn’t sure about a good notation, though I am leaning towards 23_8 to mean an 8-bit representation of 23 (subscripted, like in TeX).
Because Stupid really is stupid, it should be very easy to write static analysis code for it, enabling checks to be omitted sometimes – for example, the fact that we only subtract 1 from pad_bit if pad_bit is non-zero means that we would not have to check for underflow in that case.
Anyway, I’m a bit bemused after writing a lot of rather repetitive code for the compiler, so I think I’ll wait for reactions before commenting further – but it does seem to me that this is a project worth pursuing. The compiler itself, whilst somewhat crude, particularly since it doesn’t yet do most of the checks I suggest should be there, is pretty small and easily understood: less than 1,500 lines of Perl and YAPP. I won’t bore you with the details, but if you want a peek, here’s a tarball.
Ben Laurie - Debugging for Caja
One of the hardest parts about using Caja (which, by the way, is now far and away the most successful capability project ever) is debugging. Because of the transforms Caja must do to render your code safe, even something simple like
x.a = y.b + z.c();
becomes
$v.s($v.ro(‘x’), ‘a’, $v.r($v.ro(‘y’), ‘b’) + $v.cm($v.ro(‘z’), ‘c’, [ ]));
if we ignore all the wrapping code that is generated. Whilst you can certainly get used to reading this and translating it back into your original source in your head, so you can use, say, Firebug to debug, it’s pretty painful at best.
So I was pleased to see that the Closure Inspector now supports Caja debugging.
By the way, if you want to play with Caja, it’s now easier than ever, using the new Appspot-based Caja Playground.
Ben Laurie - Sustainable Energy
I’ve become very interested in sustainable energy lately, not least because I now own a farm in Wales, which has all sorts of stuff like wind, water and trees on it. So, I was very pleased when my mother-in-law gave me a copy of Sustainable Energy – Without the Hot Air
So, I did a quick calculation, using the figures from the book. Each person needs 36 kWh/day for heating. Wood at its best has an energy density of 5.5 kWh/kg, so that means I need about 6.5 kg of wood per day or about 2.4 tons a year. Around these parts, we can produce (sustainably) about 10 dry tons per hectare of wood, so I need about .25 of a hectare to produce all the wood I need forever. Well, until the sun goes out. Of course, it’s a 5-bedroom house, so we need maybe 1.5 hectares for the whole house – which is just under 4 acres, for the more traditional. I can do that, quite easily. But could everyone? If everyone in the UK were to use wood for heating, we’d need about 15,000,000 hectares of wood. The UK is about 24,500,000 hectares. Oops. And that, my friends, is the difference between sustainable and renewable.
The book is also available for free in PDF form from the author’s website. But don’t forget that if you buy the book, you are sequestering carbon!
By the way, a minor historical note, David MacKay is also responsible for Dasher, which is a very cool piece of software – and so I think I may have met him a few years back in a pub in Cambridge, when FreeBSD, Apache and Dasher folk drank beer together. If so, I am honoured to have had beer with such a clear thinker!
My transatlantic friends should note: this book is calibrated for the UK. I’m sure it’s possible to transliterate it to the US or elsewhere, but it’ll take some work.
ShmooCon News - Now everyone can see ShmooCon
Either due to schedule conflicts, sold out tickets, or ninja attack, there are a number of folks who won't be joining us the first weekend in February.To that end, we'll be streaming ShmooCon live via uStream this year. We've done some initial testing and we believe it should all go without a hitch. That said, as with anything you try for the first time, there will be hiccups. However, if all goes according to plan, you'll be able to watch live ShmooCon talks from the comfort of your couch and with no pressure to shower.
We'll post info on where to tune in to watch right prior to the start of the con.
Ben Laurie - Is SSL Enough?
In response to my post on OAuth WRAP, John Panzer asks
[A]re you arguing that we shouldn’t rely on SSL? OAuth WRAP (and for that matter, OAuth 1.0 PLAINTEXT) rely on SSL to mitigate the attacks mentioned. Ben Adida’s argument is that SSL libraries won’t save you because people can misconfigure and misuse the libraries. But OAuth libraries will save you; apparently they can’t be misconfigured. There seems to be a small contradiction here. Especially since OAuth is much less mature than SSL.
I am not saying we shouldn’t rely on SSL, and I am not arguing that SSL libraries won’t save you (though it’s pretty clear that they are often misused – in particular, failure to check that the certificate presented corresponds to the server you were trying to connect to is a fantastically common error, it seems – in other words, SSL is often used in a mode that gives no protection against a man-in-the-middle). What I am saying is that when you design a security protocol, you should design something that addresses the appropriate threat model. Now, I am not aware of a published threat model for OAuth WRAP, so I instead apply the one I have in my head for authentication protocols, since that’s what it is. In my off-the-top-of-my-head model of authentication protocols there are various properties I want
- No replays: if someone gets hold of a request, they should not be able to replay it.
- Not malleable: if someone sees one request, they should not be able to create another correct one.
- No credential equivalent: the server should not be able to create a request that looks like it came from the client.
And so forth. I will not create a complete set of requirements, because that’s a tough job, and it’s nearly time for supper. However, you can easily see that OAuth WRAP does not satisfy any of these requirements. Nor, incidentally, do username/password logins.
Now, you can argue that the use of SSL makes the requirements redundant, and I have some sympathy for that argument but, as we have seen, SSL can have flaws in it. And, in fact, for example, the current flaw is perfect for attacking OAuth WRAP – I could inject a request in front of your WRAP request that causes your credential to be sent to me, and now, bingo, I can do anything at all that you can do. A well designed protocol would not suffer from this issue.
But even if we ignore the weakness in SSL, there are other requirements that are not met – in particular, the “no credential equivalent” requirement is not addressed at all by SSL. The server can easily fabricate a request and claim I made it. This is a terrible property for a protocol that is supposed to be used to protect my assets.
So, in short, I agree that you can use SSL to make a crappy protocol less crappy. But the right thing to do is to figure out what your requirements are (really, not fudge them so they fit your protocol, as I rather suspect will happen here) and then design a protocol that satisfies them. If that protocol happens to be “password over SSL” then great, you’re home and dry. But I do not see how any modern, well-designed authentication protocol could be that way.
ShmooCon News - Keynote Speakers Announced
ShmooCon and The Shmoo Group are pleased to announce this year's keynote address. Steve Dispensa and Marsh Ray will be presenting their first hand account and technical details behind the discovery of the TLS Authentication Gap vulnerability.The ShmooCon schedule is now online as are most of the talk descriptions. Check it out!
ShmooCon News - Round One Sold Out
In record time, at least for November ticket sales. Next round of tickets will be up for grabs on December 1st.ShmooCon News - Link to Ticket Sales
It really was there folks...at the bottom of the page. Yes, we should have top posted and made it easier on all of you. It was an inadvertent overlook on our part and we're sorry.That being said, it is a hacker con. Maybe next time we'll put the link in the middle. ;)
Also, there are still a small number of tickets in the system that age out as people don't complete the reservation process. You can continue to try to get a reservation code, but type fast as you'll be racing with others to try and get the same tickets. We'll notify you here when tickets are actually sold out.
One more mea culpa. We're aware we need to change the text that pops up when all tickets are in the reserve process and, at that moment, unavailable. While that won't really change anything, we feel it should be more informative than simply "come back in December."
ShmooCon News - Ticket Sales
Are live...get 'em while they're hot.ShmooCon News - Hotel Code
Once you get your ticket, think about getting a room. Already booked a room? We know some of you have. Call back and get it moved into the ShmooCon Block.Rooms at the Wardman Park Marriott will run $179/night for a single/double. Enter or reference code OCTOCTA when making your reservation to get this rate.
ShmooCon News - Important information regarding ticket sales
Folks, it's less than 24 hours until the first round of ticket sales. We've implemented some major changes this year and it's important that you understand the process prior to the rush tomorrow. Please visit and read the information on the registration page followed by the information on the cart page.ShmooCon News - Contests!
ShmooCon just wouldn't be the same without the following events:Hack-or-Halo - Two tournaments in one, pitting elite hacking know how against mad gaming skills.
Hacker Arcade - Our own high-tech version of gaming for tokens - crypto tokens!
Barcode Shmarcode - Back for the second year in a row, the idea here is to bring your barcode to ShmooCon in style.
TF2 Lan Party - Because gaming is fun.
ShmooBall Launcher Contest - ShmooCon is nothing without ShmooBalls and it was only a matter of time before this contest came into play.
Check it out!
ShmooCon News - More Speakers Announced
Here you go folks - this is almost everyone. We'll have bios and abstracts up by the end of the weekend.- Blackberry Mobile Spyware - The Monkey Steals the Berries - Tyler Shields
- WiFi Bombs shaken not stirred - Ben Smith, Terrence Gareau
- honeyM: A Framework For Virtual Mobile Device Honeyclients - Karlo Navas, David Brasefield, Nate Grunzweig, TJ OConnor
- WLCCP - Analysis of a Potentially Flawed Protocol - Enno Rey, Oliver Roeschke
- Jsunpack-network Edition Release: JavaScript Decoding and Intrusion Detection - Blake Hartstein
- PCI: An Existential Threat To Security As We Know It? - Joshua Corman, Michael Dahn, Anton Chuvakin, Jack Daniel
- How To Be An RSol: Effective Bug Hunting in Solaris - Matt Hillman
- Bluetooth Keyboards: Who Owns Your Keystrokes? - Michael Ossmann
- Exposed | More: Attacking the Extended Web - Nathan Hamiel
- BaSO4: A Dynamic Dataflow Analysis Tool for Auditing and Reversing - Dion Blazakis
- A Tale of Infrastructural Weaknesses in Distributed Wireless Communication Services - Zack Fasel
- The New World of Smartphone Security - What Your iPhone Disclosed About You - Trevor Hawthorn
- Becoming Jack Flack: Real Life Cloak & Dagger - Taylor Banks, Adam Bregenzer
- De Gustibus - Adventures in Hacking Taste - Sandy Clark
- Flying Instruments-Only: Legal and Privacy Issues in Cloud Computing - Richard Goldberg
- Worst Practices in Facility Secuirty - Shane Lawson
- Tales from the Crypto - G. Mark Hardy
- Detection of rogue access points using clock skews: does it really work? - Sergey Bratus, Anna Shubina, Chrisil Arackaparambil
- Pulling the Plug: Security Risks in the Next Generation of Offline Web Applications - Michael Sutton
- Guest Stealing...The VMware Way - Justin Morehouse, Tony Flick
- Windows File Pseudonyms - Dan Crowley
- Information disclosure via P2P networks: Why stealing an identity via Gnutella is like clubbing baby seals. - Larry Pesce, Mick Douglas
ShmooCon News - More Speakers
Round 2 of Speaker Selection has been completed. The following talks are officially accepted:- GPU vs. CPU Supercomputing Security Shootout - Collin Brack
- Closing the TLS Authentication Gap - Steve Dispensa and Marsh Ray
- Social Zombies II: Your Friends Need More Brains - Tom Eston, Kevin Johnson, Robin Wood
- Cyborg Information Security: Defense Against the Dark Arts - Esteban Gutierrez and Adam Cecchetti
- The Friendly Traitor: Our Software Wants to Kill Us - Kevin Johnson and Mike Poor
- Ring -1 vs. Ring -2: Containerizing Malicious SMM Interupt Handlers on AMD-V - Pete Markowsky
- Stealing Guests...The VMware Way - Justin Morehouse and Tony Flick
- GSM: SRSLY? - Chris Paget and Karsten Nohl
- The Splendiferous Story of Archive Team and the Rapidly Disappearing Digital Heritage - Jason Scott
ShmooCon News - 0wn the Con - the online version
Well, another round of ticket sales is in the books. Thanks to everyone who bought tickets (and thanks to those who tried but didn't make it). We've received a lot of feedback in the last few weeks including emails, tweets, blog posts, and even phone calls from our closest friends. Some was positive, some was negative - but given the amount of comments, we're going to address much of it here.Ticket Sales Methodology:
We often get asked "why do you sell tickets the way you do?" The ShmooCon ticket sales process has really evolved through the years. However, for the last few, at the initial urging of our attendees, we've employed a "pay what you think its worth" model ala Burning Man. The idea is that you'd pay based on your ability to pay or what you think the value of the con really is. So we provided three price options, the uppermost of which has always scored you a free t-shirt. Other than that, the tickets all provide the same access. As we've stated before this has pretty much devolved into a "pay what you can get" scenario. There are many pros and cons associated with this, but overwhelmingly the feedback from last year was not to change the system.
And so ShmooCon ticket sales continue to be somewhat of an adventure. Demand has gone up each year, and the number of people trying to buy tickets at each sales cycle seems to have grown. Every single sales cycle has helped us learn more about our cart, our systems, and our attendees. We've constantly tried to make changes to the cart based on what we've learned; sometimes the changes work out, sometimes they don't. Honestly, ticket sales days are very stressful for us because even with testing and preparation, there are enough unknown variables to keep things exciting.
Examples of Lessons Learned:
When you say ticket sales will go live on Nov 1st - state a time. We had folks up at midnight in all time zones. (ShmooCon III)
However much memory you think is needed, it won't be enough (ShmooCon IV)
Unlimited amounts of Apache connections is a very bad thing (ShmooCon V)
Going Forward:
This year there have been a number of changes including more internal documentation to help us plan and execute, more external documentation so you know how things work, and a reserve then pay model based on what cons like BlizCon have done. We also threw in a CAPTCHA to stop the folks who had written bots to buy as many tickets as possible. Overall, these changes have had a positive effect on the registration system. Still, in the second round, there were obvious load issues on the server. We've got a new machine built and ready to replace the old one. The new machine has a lot more horsepower and we'll have it in place in time for the January 1st sales cycle.
As to what will happen with the sales model next year - we just don't know yet. We're reviewing data, crunching numbers and will be soliciting feedback over the next few months. There are a number of possibilities all with their own good and bad sides.
Limited Attendance:
ShmooCon limits attendance to a preset number. This, as many have pointed out, is very different from the standard hacker/security con. ShmooCon is not backed by a big corporation, ShmooCon is not out to dominate the conference industry, and ShmooCon isn't trying to steal all your money. We are, however, trying to throw a first rate con at a reasonable price and end up with an event that the attendees feel is valuable and pushes the information security ball forward. To help us plan better and to limit our potential financial liability, we limit the number of tickets we sell. We find this makes everyone happy and prevents us from losing our shirts if things go badly. It also helps us to create an environment for our attendees (think not too big, not too small) that is a big part of the ShmooCon experience.
Ultimately there are many more people who want to attend ShmooCon than we can accommodate. Woe is us, right? But we understand this is a real issue as many people who want to participate in ShmooCon are unable to get tickets. We do our best to get content online and make our conference as open as possible. We also support many other great cons throughout the world which over the years has included yStS, Phreaknic, ToorCon, LayerOne, and Notacon. If you can't make it to ShmooCon, or even if you can, check out these other worthy events.
Feedback:
Finally, we take all your feedback (positive and negative) very seriously. At every ShmooCon we host a talk called "0wn the Con" where we provide tons of info on our infrastructure, our organization, and our finances. The videos and slides from previous years are online and you're welcome to view them. The entire Shmoo Group and all the ShmooCon volunteers take ShmooCon seriously and we do our best to provide you the best con possible. So keep the feedback coming, and thanks for your help in making ShmooCon better.
ShmooCon News - Ticket Purchasing
The vast majority of you have already come back and purchased your reserved tickets - Thank you! For the small number of you who haven't, you've got until noon EST tomorrow, Dec. 3, to get that done.If you've written info regarding your purchase (international inquiries and others), you'll be hearing from us shortly if you haven't already.
Thanks again!
ShmooCon News - Round Two Ticket Sales
Before our news entry post about ticket sales being open could even post, we were sold out. This is a new Round Two ShmooCon record.Those of you who got reservation codes can come back beginning at 1pm EST to complete your purchase. This will remain open for at least 24 hours. We will give notice here prior to shutting that down.
ShmooCon News - Ticket sales and other updates
Ticket Sales2nd round of ticket sales begins tomorrow, Dec 1st at Noon EST. We'll be watching...
Speakers
The early round of speaker selection is done and we're happy to announce the beginning of our line up so far:
- Economics of Cyber Crime - Peter Guerra
- Better Approaches to Physical Tamper Detection - Roger G. Johnston and Jon S. Warner
- DIY Hard Drive Diagnostics: Understanding a Broken Drive - Scott Moulton
- Build your own Predator UAV @ 99.95% Discount - Michael Weigand
Sponsors
A big thanks to our newest sponsors:
More to come in the days and weeks to come - keep watching this space!
ShmooCon News - CFP closes tomorrow
Just a reminder that tomorrow, Friday, November 20, is the last day to turn in any CFP submissions. We will accept submissions up until midnight EST.ShmooCon News - Updates
A few new features for all of you:Lost your barcode? Regenerate it using our barcode generator.
Need a receipt? Get yours here.
ShmooCon News - Reserved Tickets
An overwhelming majority of folks who were able to reserve tickets yesterday have already come back to purchase - thank you! The rest of you have until Noon EST tomorrow (Tuesday) to redeem your reservation codes. After that, those tickets will be released and added into the numbers for the December sales date.Also, yesterday was the early submission deadline for the CFP. We received a record 86 talks by midnight. We will be choosing a small number of talks from submissions received up to this point. If you're not selected this round, don't worry - you're still in the running. Haven't submitted yet? There's still time. You still have until the 20th to turn something in.
ShmooCon News - And so this stays at the top
Reposted:Once you get your ticket, think about getting a room. Already booked a room? We know some of you have. Call back and get it moved into the ShmooCon Block.
Rooms at the Wardman Park Marriott will run $179/night for a single/double. Enter or reference code OCTOCTA when making your reservation to get this rate.
Ben Laurie - TLS Renegotiation Fix: Nearly There
Finally, after a lot of discussion, the IESG have approved the latest draft of the TLS renegotation fix. It is possible it’ll still change before an RFC number is assigned, but it seems unlikely to me.
But that doesn’t mean there isn’t plenty of work left to do. Now everyone has to implement it (in fact, many have already done so, including tracking the various changes as the I-D was updated), interop test with each other and roll out to clients and servers. And even then it isn’t over, since until clients are (mostly) universally updated, servers will have to allow old clients to connect and clients may have to be prepared to connect to old servers. In the case of a new server and an old client, it doesn’t hugely matter that the client has not been updated because it is defended by the server, which should not allow a renegotiation to occur if the client is old. However, in the case of an old server and a new client, or an old server and an old client, then there’s a problem – the client could be attacked. Obviously a new client can detect it is talking to an old server, and decline to play, but for some transitional period, it seems likely that clients will have to tolerate this, perhaps warning their user.
We could summarise the situation like this:
| Client | |||
|---|---|---|---|
| Old | New | ||
| Server | Old | vulnerable | vulnerable but client is aware, client should decline or at least warn |
| New | not vulnerable if renegotiation is forbidden, client is unaware | not vulnerable, everyone is aware | |
Ben Laurie - Spamassassin FAIL
I use Spamassassin for spam filtering (anyone think there’s anything better out there these days?) and I noticed today that I’m getting a bunch of false positives. It turns out that this is because Spamassassin has a rule called FH_DATE_PAST_20XX which has kicked in now the date is 2010. Oops. Particularly oops because it has a score of 3.2 in my setup. Upgrading Spamassassin may or may not fix this, but for a quick fix, put
score FH_DATE_PAST_20XX 0
in your local.cf file, which, in my case at least, lives in /usr/local/etc/mail/spamassassin.
Ben Laurie - Security Is Hard: Live With It
I’ve been meaning to summon the energy to write about OAuth WRAP. It’s hard to do, because like OpenID, OAuth WRAP is just so obviously a bad idea, it’s difficult to know where to start. So I was pleased to see that Ben Adida saved me the trouble.
I understand. Security is hard. Getting those timestamps and nonces right, making sure you’ve got the right HMAC algorithm… it’s non-trivial, and it slows down development. But those things are there for a reason. The timestamp and nonce prevent replay attacks. The signature prevents repurposing the request for something else entirely. That we would introduce a token-as-password web security protocol in 2010 is somewhat mind-boggling.
Exactly. The idea that security protocols should be so simple than anyone can implement them is attractive, but as we’ve seen, wrong. But does the difficulty of implementing them mean they can’t be used? Of course not – SSL is fantastically hard to implement. But it is also fantastically widely deployed. Why? Because there are several open source libraries that do everything for you. Likewise every crypto algorithm under the sun is hard to implement, but there’s no shortage of libraries for them, either.
Clearly the way forward for OAuth is not to dumb it down to the point where any moron can implement it, the way forward is to write libraries that implement a properly secure version, and have everyone use them.
If the amount of effort that has been wasted on OAuth WRAP (and OpenID) had instead been put instead into writing code for the various platforms then we would probably now have pretty much universal support for OAuth and no-one would be whining that it’s too hard to implement.
Instead, we will spend the next decade or two clearing up the mess that we seem to be intent on creating. It makes me tired.
ShmooCon News - That was fast...
Another round of ticket sales, another adventure. The good news is the new server has way more capacity than the last and the webpage was responsive the entire time. The bad news is we inadvertently redirected the reservation code page to an insecure page (which the webserver won't allow). We updated the landing page with the right link once we realized the mistake, but at that point we were already so close to selling out that the majority of you were still effected.The good news is we have logs and have already sent an email to everyone who made it through the reservation process. If you haven't received an email by now, please try again next year - but also please check back in the weeks leading up to the con as we have more surprises up our sleeves. No not more tickets, but good things none-the-less.
Happy New Year everyone. Our resolution? Do everything we can for a successful ticket sales experience for ShmooCon 2011.
ShmooCon News - Ticket Sales Tomorrow
Just a reminder - sales go live at NOON EST.Happy New Year's Eve to all of you!
ShmooCon News - Contests!
ShmooCon just wouldn't be the same without the following events:Hack-or-Halo - Two tournaments in one, pitting elite hacking know how against mad gaming skills.
Hacker Arcade - Our own high-tech version of gaming for tokens - crypto tokens!
Barcode Shmarcode - Back for the second year in a row, the idea here is to bring your barcode to ShmooCon in style.
TF2 Lan Party - Because gaming is fun.
ShmooBall Launcher Contest - ShmooCon is nothing without ShmooBalls and it was only a matter of time before this contest came into play.
Check it out!
ShmooCon News - More Speakers Announced
Here you go folks - this is almost everyone. We'll have bios and abstracts up by the end of the weekend.- Blackberry Mobile Spyware - The Monkey Steals the Berries - Tyler Shields
- WiFi Bombs shaken not stirred - Ben Smith, Terrence Gareau
- honeyM: A Framework For Virtual Mobile Device Honeyclients - Karlo Navas, David Brasefield, Nate Grunzweig, TJ OConnor
- WLCCP - Analysis of a Potentially Flawed Protocol - Enno Rey, Oliver Roeschke
- Jsunpack-network Edition Release: JavaScript Decoding and Intrusion Detection - Blake Hartstein
- PCI: An Existential Threat To Security As We Know It? - Joshua Corman, Michael Dahn, Anton Chuvakin, Jack Daniel
- How To Be An RSol: Effective Bug Hunting in Solaris - Matt Hillman
- Bluetooth Keyboards: Who Owns Your Keystrokes? - Michael Ossmann
- Exposed | More: Attacking the Extended Web - Nathan Hamiel
- BaSO4: A Dynamic Dataflow Analysis Tool for Auditing and Reversing - Dion Blazakis
- A Tale of Infrastructural Weaknesses in Distributed Wireless Communication Services - Zack Fasel
- The New World of Smartphone Security - What Your iPhone Disclosed About You - Trevor Hawthorn
- Becoming Jack Flack: Real Life Cloak & Dagger - Taylor Banks, Adam Bregenzer
- De Gustibus - Adventures in Hacking Taste - Sandy Clark
- Flying Instruments-Only: Legal and Privacy Issues in Cloud Computing - Richard Goldberg
- Worst Practices in Facility Secuirty - Shane Lawson
- Tales from the Crypto - G. Mark Hardy
- Detection of rogue access points using clock skews: does it really work? - Sergey Bratus, Anna Shubina, Chrisil Arackaparambil
- Pulling the Plug: Security Risks in the Next Generation of Offline Web Applications - Michael Sutton
- Guest Stealing...The VMware Way - Justin Morehouse, Tony Flick
- Windows File Pseudonyms - Dan Crowley
- Information disclosure via P2P networks: Why stealing an identity via Gnutella is like clubbing baby seals. - Larry Pesce, Mick Douglas
Ben Laurie - Extended Subsets
When dealing with the recent SSL fun, I met Marsh Ray, who found the problem in the first place. Marsh has a website, extendedsubset.com. I went looking for what an extended subset was one day and was a bit surprised to discover there was no such thing. So, after consulting with Marsh, I figured I should fix that and write down with some measure of rigour what an extended subset is.
Ben Laurie - How To Keep Your Facebook Stuff Private
Apparently, it is Facebook’s considered opinion that the way to avoid sharing data you don’t want shared is to not enter it
Barry Schnitt, a Facebook spokesman, said users could avoid revealing some information to non-friends by leaving gender and location fields blank.
I guess they’d agree, then, that the best option is to not use Facebook at all.