Links

I do not represent my employer in this post.

Eric Schmidt allegedly said

“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’.

Share This

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.

Share This

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.

Share This

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?).

Share This

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.

Share This

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.

Share This

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";

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.

Share This

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.

Share This

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:

Share This

Wietse Venema has a nice analysis showing how an attack on Postfix doesn’t work. The core point here is that in turn-based protocols the common implementation is such that the server (or client – let’s call it an agent) will consume input from the OpenSSL layer character by character, in effect. This means that OpenSSL in turn will only consume a single SSL packet at a time, in order to provide input to the agent. The agent will then send output before reading further input. That output will be encrypted to the man-in-the-middle, because the OpenSSL layer has not yet processed the packets with the renegotiation in them. The victim will be unable to read the output, so the attacker has no option but to consume it. This means the attacker can execute arbitrary commands before handing over to the victim, but he can only hijack the very first command the victim sends – by sending an incomplete command himself, followed by the renegotiation. This makes it hard to kid the victim into doing anything interesting before something goes awry with the protocol and one end or the other gives up.

This defence only works if the application layer does not greedily consume from the OpenSSL layer – if you read everything OpenSSL has got, then the renegotiate will occur before you start sending responses.

Wietse thinks this means that Postfix can’t be attacked in any interesting way. My experience of making such claims has been unfortunate, so I’ll reserve judgement. My advice is still to upgrade to 0.9.8l if you can (or whatever fix your vendor is offering for this issue). If you need 0.9.8m in a hurry because you need renegotiation and can update both ends, let me know.

However, I rather suspect (but definitely don’t know) this will save many turn-based protocols from severe attacks, though I’m prepared to bet there are interesting corner cases.

Incidentally, Adam Langley pointed out to me that if protocols had included a sentinel character – i.e. a character that could only ever appear at the start of a command, then some attacks against HTTP would fail, and also even the hijacking of the victim’s first command would not be possible in SMTP, though arbitrary prefixing would work, still. Simply numbering the commands sent would fix that, though – and defeat some injection attacks (not that these are currently possible in SSL). These kinds of measures would be interesting defences in depth for future protocols. Keeping a running hash sounds like a better idea to me, though.

Share This

Are we having fun yet? First, thanks to Benson, the only person so far to have expressed any kind of appreciation for the work we volunteers do.

Now to Q&A.

• Several people have pointed out that Adam Langley is unhappy that I (and others) have maligned TLS. Apparently
  

  …it’s not a flaw in TLS. The TLS security properties are exactly what was intended.

  Isn’t that wonderful? Notice how much more secure the world became now we’ve got that cleared up.

  Also notice how this “intended” property was so carefully explained, and how everyone involved immediately noticed that every single protocol that is layered on top of TLS got this wrong and had them fix it. Not.

  I’m not particularly interested in the blame game. I don’t really care who’s at fault here. What I care about is fixing the problems we have. TLS is broken. TLS is not broken. Whatever. I still seem to be patching code, either way.

  By the way, Adam is incorrect in supposing this is tied to client certificates – this seems to be a common confusion. Any TLS session can be hijacked, so long as the server allows renegotiation. Which pretty much anything based on OpenSSL does.

• Many people seem to think that fixing this (or working around it, as in OpenSSL 0.9.8l) will break session resumption. I’m not sure where this comes from, but it won’t.
• On a related note: can a resumed session be attacked? I don’t quite have the energy to test this, but I assume it can – although it would be a weird thing to do, I believe a client is allowed to resume a session during a renegotiation. So, to the server, this would look like the client connected, negotiated a new session, said some stuff, then renegotiated an old session and continued.
• On why this isn’t the same as XSRF, when considering HTTPS – I forgot to mention that the attacker can use methods other than GET or POST, which is all you can do with XSRF.
• Again on XSRF: those who think no clicks are necessary for XSRF are wrong – the victim must first follow a link to your evil page.
• Is this really a MitM attack? Eric Rescorla correctly points out it is rather more limited than a classic MitM attack, but I don’t like his term either. When I first heard of it I called it a blind prefix injection attack. Which is still my preferred term.

So, what next? Eric Rescorla et al have proposed a TLS extension which, when implemented by both clients and servers, fixes this problem by cryptographically binding the two sessions (before and after renegotiation) together.

I have today committed code (mostly written by Eric Rescorla) implementing this extension to the OpenSSL tree, in the OpenSSL_0_9_8-stable branch. This is to allow review, of course, but also interop testing. An earlier version of this, which was based on 0.9.8l, was tested against a completely independent implementation by Nasko Oskov. Unfortunately we (the OpenSSL team) later decided that 0.9.8m should be based on the head of the 0.9.8 branch so that it would include various other bug and security fixes, so this version is not exactly the same as the one I tested with Nasko. I will be re-testing at the earliest opportunity.

Implementing and testing this fix has raised a problem, though. One of the nice features of the extension is that it is back compatible with old clients, so long as they don’t try to renegotiate. However, there is no corresponding mechanism for back compatibility with old servers. A client connecting to an old server has no way to know whether an attack occurred or not – only the server can detect that (it sees a renegotiation) – but since the server is old, it won’t know this is bad. I don’t have a solution to this problem at this time. Perhaps we shouldn’t try to solve it, and just require servers to upgrade.

Share This

A lot can happen in a day. Yesterday the news broke that SSL was compromised. We immediately (OK, it took about 10 hours) released a new version of OpenSSL, 0.9.8l, which mitigates the problem by completely disabling renegotiation. Obviously this will break some sites, and so is not a full fix, so the next step is to implement Eric Rescorla’s TLS extension. However, before I get on with that, it seems I have a few questions to answer.

Firstly, I must thank the anonymous poster who said “OpenSSL is written by monkeys”. But dude, you should’ve included the link. I’ve been meaning to link to that for ages. Well, days.

Secondly, as Marsh said, there is a better answer for people who need renegotiation. This is the extension mentioned above. It won’t work unless clients also implement that, but we are working on that, too (and clearly any client that uses OpenSSL will get it for free as soon as I get the next version out).

To the bloke who asked about ISA and OWA: I have no idea what either of those are.

Does this affect SGC (Server-Gated Cryptography)? I don’t actually know. I think it does, because I think SGC uses renegotiation, but I am not sure. If anyone knows, comment!

To the “but this is just XSRF” (Cross-site request forgery) guy:

• XSRF does not give the attacker control over headers.
• Your attack didn’t work on me: I didn’t click the link.
• HTTP is not the only protocol that uses SSL.

Though the fact that this attack doesn’t actually make HTTP much worse is a pretty damning indictment of HTTP (and HTML)!

Will this patch break session resumption? No – and nor will the 0.9.8l release, which does the same thing more elaborately and correctly.

Finally, even once we’ve implement the extension it seems to me this is not really the true fix – really applications should be aware of renegotiations and not carry trust across their boundaries. But more on that later, I’ve got code to write.

Share This

For the last 6 weeks or so, a bunch of us have been working on a really serious issue in SSL. In short, a man-in-the-middle can use SSL renegotiation to inject an arbitrary prefix into any SSL session, undetected by either end.

To make matters even worse, through a piece of (in retrospect) incredibly bad design, HTTP servers will, under some circumstances, replay that arbitrary prefix in a new authentication context. For example, this is what happens if you configure Apache to require client certificates for one directory but not another. Once it emerges that your request is for a protected directory, a renegotiation will occur to obtain the appropriate client certificate, and then the original request (i.e. the stuff from the bad guy) gets replayed as if it had been authenticated by the client certificate. But it hasn’t.

Not that the picture is all rosy even when client certificates are not involved. Consider the attacker sending an HTTP request of his choosing, ending with the unterminated line “X-Swallow-This: “. That header will then swallow the real request sent by the real user, and will cause any headers from the real user (including, say, authentication cookies) to be appended to the evil request.

It’s obviously going to take a little while for the world to patch this – and since the news is spreading like wildfire I’ve put up a patch to OpenSSL that bans all renegotiation. I’m sure an official release will follow very shortly.

Note that the patch is against the head of the OpenSSL 0.9.8 development tree (that is, it is against 0.9.8l-dev). You may have to do a little work to patch against other versions. And if you intend to deploy this patch permanently, please change at least the textual version of the version number, which you can find in crypto/opensslv.h. Also note that if you need renegotiation for your site to work, I have no solution for you, other than you redesign your site. Sorry.

Share This

AES in cartoon form – a really nice explanation. Example code to go with it, too.

Share This

I’ve been meaning for some time to point out that it’s been well over a year since Microsoft bought Credentica and still no sign of any chance for anyone to use it. Kim Cameron has just provided me with an appropriate opportunity.

Apparently the lack of action is because Microsoft need to get a head start on implementation. Because if they haven’t got it all implemented, they can’t figure out the appropriate weaseling on the licence to make sure they keep a hold of it while appearing to be open.

if you don’t know what your standards and implementations might look like, you can’t define the intellectual property requirements.

Surely the requirements are pretty simple, if your goal is to not hoard? You just let everyone use it however they want. But clearly this is not what Microsoft have in mind. They want it “freely” used on their terms. Not yours.

Share This

Ben Adida says nice things about Google Wave. But I have to differ with

… follows the same trust patterns as email …

Wave most definitely does not follow the same trust patterns as email, that is something we have explicitly tried to improve upon, In particular, the crypto we use in the federation protocol ensures that the origin of all content is known and that the relaying server did not cheat by omitting or re-ordering messages.

I should note, before anyone gets excited about privacy, that the protocol is a server-to-server protocol and so does not identify you any more than your email address does. You have to trust your server not to lie to you, though – and that is similar to email. I run my own mail server. Just saying.

I should also note that, as always, this is my personal blog, not Google’s.

Share This

Today Google announced Google Wave. I’m not going to talk about Wave itself, just search for it and get a ton of articles. Suffice it to say that it is awesome.

What I want to mention is the Wave Federation Protocol, and in particular, General Verifiable Federation, which is the part my talented colleague Lea Kissner and I worked on. I know I’m a crypto geek, but I think this protocol is pretty interesting, with applications wider than just Google Wave, since it creates a platform for building federated messaging systems in which you do not trust intermediaries.

Lea and I welcome feedback on the protocol, which we are sure is full of mistakes right now, as we were in a bit of a rush to hit today’s deadline…

(And for those friends who are probably wondering now if this is why I went to Australia earlier this year, the answer is, unsurprisingly: yes).

Share This

A lot of solutions to all our problems begin with “first find a public key for the server”, for example, signing XRD files. But where can we get a public key for a server? Currently the only even slightly sane way is by using an X.509 certificate for the server. However, there are some problems with this approach

1. If you are going to trust the key, then the certificate must come from a trusted CA, and hence costs money.
2. Because the certificate is a standard X.509 certificate, it can be used (with the corresponding private key, of course) to validate an HTTPS server – but you may not want to trust the server with that power.
3. The more we (ab)use X.509 certificates for this purpose, the more services anyone with a certificate can masquerade as (for the certified domain, of course).

One obvious way to fix these is to add extensions to the certificates that prevent their use for inappropriate services. Of course, then we would have to get the CAs to support these extensions and figure out how to validate certificate requests that used them.

But I have to wonder why we’re involving CAs in this process at all? All the CA does is to establish that the person requesting the certificate is the owner of the corresponding domain. But why do we need that service? Why could the owner of the domain not simply include the certificate in the DNS – after all, only the owner of the domain can do that, so what further proof is required?

Obviously the answer is: DNS is not secure! This would allow anyone to easily spoof certificates for any domain. Well, yes – that’s why you need DNSSEC. Forgetting the details of DNSSEC, the interesting feature is that the owner of a domain also owns a private key that can sign entries in that domain (and no-one else does, if the owner is diligent). So, the domain owner can include any data they want in their zone and the consumer of the data can be sure, using DNSSEC, that the data is valid.

So, when the question “what is the public key for service X on server Y?” arises, the answer should be “look it up in the DNS with DNSSEC enabled”. The answer is every bit as secure as current CA-based certificates, and, what’s more, once the domain owner has set up his domain, there is no further cost to him – any new keys he needs he can just add to his zone and he’s done.

Does DNSSEC have any other uses? OK, it would be nice to know that the A record you just got back corresponds to the server you were looking for, but if you trust a connection just on the basis that you used the right address, you are dead meat – you’ll need some key checking on top of it (for example, by using TLS) to avoid attacks by evil proxies (such as rogue wifi hotspots) or routing attacks and so forth. For me, the real value in DNSSEC is cryptographic key distribution.

Share This

From time to time I bemoan the fact that much of good practice in cryptography is craft knowledge that is not written down anywhere, so it was with interest that I read a post by Michael Roe about hidden assumptions in crypto. Of particular interest is this

When we specify abstract protocols, it’s generally understood that the concrete encoding that gets signed or MAC’d contains enough information to unambigously identify the field boundaries: it contains length fields, a closing XML tag, or whatever. A signed message {Payee, Amount} K_A should not allow a payment of $3 to Bob12 to be mutated by the attacker into a payment of $23 to Bob1. But ISO 9798 (and a bunch of others) don’t say that. There’s nothing that says a conforming implementation can’t send the length field without authentication.

No of course, an implementor probably wouldn’t do that. But they might.

Actually, in my extensive experience of reviewing security-critical code, this particular error is extremely common. Why does Michael assume that they probably wouldn’t? Because he is steeped in the craft knowledge around crypto. But most developers aren’t. Most developers don’t even have the right mindset for secure coding, let alone correct cryptographic coding. So, why on Earth do we expect them to follow our unwritten rules, many of which are far from obvious even if you understand the crypto?

Share This

A long time ago my sometimes collaborator, Rachel Willmer, and I started work on a BSD-licensed OpenPGP library, sponsored by Nominet.

Things slowed down a bit when, shortly after getting the initial code done, I got hired by Google – that was a bit distracting. But Rachel has been plugging away ever since, with occasional interference from me. So, I’m pleased to announce that we’ve reached the point of a somewhat feature complete release, for some value of “feature complete”, OpenPGP:SDK V0.9.

Of course, its an open source project, so contributions and bug reports are welcome. More to the point, if anyone would rather use a library than shell out to gpg, I’d be happy to help them figure out how.

Share This