Last week I found an interesting blog post by Antonio Sanso on the subject of a somewhat obscure standards document called RFC5114. RFC’s are proposals for internet standards, and this particular one lists a set of very large prime numbers for use in a cryptographic process called Diffie-Hellman key exchange.
Unless you have a deep interest in cryptography this is likely to be the kind of thing you wouldn’t pay much attention to. After all, developers love using crypto libraries like OpenSSL so that they don’t have to worry about the implementation details. So what’s all the fuss with this RFC?
Diffie-Hellman key exchange is a mechanism by which two parties can securely exchange information without having any prior arrangement (such as pre-shared passwords), and can do so even if a third party listens in to their communications. The specifics of how this works are too complicated to describe in-depth here, but in short, it relies on an interesting property of prime numbers – namely that it is very easy to multiply prime numbers together to make another number, but given the resulting number it is very hard to determine exactly which primes were used to create it. Cryptographers and computer scientists call this sort of property a one-way function.
In many ways mixing paint makes a good analogy for this. It’s very easy to mix, say, blue and yellow paint together to make green paint. However, it is then very difficult to take that green paint and separate it back out into the original blue and yellow shades. Wikipedia has a nice illustration of Diffie-Hellman using this analogy
So, how does this relate to RFC 5114?
RFC 5114 provides a list of large prime numbers, known as MODP values, for use in Diffie-Hellman key exchange. Returning to the paint analogy, this could be thought of a list of known-good paints to be used, specifying a particular brand and shade. This is useful, because it establishes standards which can be trusted – it reassures users that these particular kinds of paint have been thoroughly tested and vetted.
But what if somebody produced their own paint, then published that as a standard? Wouldn’t that potentially give them an advantage in knowing how to break these paint-based codes? After all, introducing their own carefully crafted paint into the process provides them with additional knowledge about exactly how these codes are being constructed.
And that, really, is the crux of the issue with RFC 5114. This standard has been published ostensibly as a set of reliable, tested, and vetted MODP values for use in Diffie Hellman key exchange, but where did these values really come from? Are they known to be safe? Have they been thoroughly tested? Answers to these questions are unclear.
There is no specific reason to think that the MODP values published in RFC 5114 are necessarily weakened or compromised, but the concern is that the potential is there. This is made all the more alarming by the fact that a number of widely used software projects implemented use of the RFC 5114 values with little apparent review.
Since this issue came to light there has been a considerable amount of discussion regarding RFC 5114, and as a result a number of developers have moved away from using it until it can be confirmed that these values are safe to use. It is quite likely that there is no actual security problem here, and that these values are perfectly safe to use, but it raises an interesting problem: In the security community we often use open source products precisely because they are transparent and can be fully inspected to rule out the possibility of back doors or secret behaviors. This sense of security, however, is contingent on somebody actually performing those reviews, and in this particular case it appears that the MODP values presented in RFC5114 were adopted by several software vendors without first verifying their trustworthiness.
At the end of the day, open source software is only really as secure as your ability to verify and trust the source. — Richard Gilmour