• Articles
    • Editorial Articles
    • Research Articles
    • WatchGuard Articles
  • The 443 Podcast
  • Threat Landscape
  • About
    • About Us
    • Contact Us
    • Contribute to Secplicity

Secplicity - Security Simplified

Powered by WatchGuard Technologies

The Mystery of RFC 5114

November 3, 2016 By Richard Gilmour

Security

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

Share This:

Related

Filed Under: Editorial Articles Tagged With: Infosec news

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

The 443 Podcast

A weekly podcast featuring the leading white-hat hackers and security researchers. Listen Now
the 443 podcast

Threat Landscape

Filter and view Firebox Feed data by type of attack, region, country, and date range. View Now
threat landscape

Top Posts

  • Cybersecurity News: Free Cybersecurity Training, TrickBot Group Exposed, Major GoDaddy Breach, and Russia to Legalize cybercrime?!
  • US National Cybersecurity Strategy
  • Here Come The Regulations
  • Cybersecurity’s Toll on Mental Health

Email Newsletter

Sign up to get the latest security news and threat analysis delivered straight to your inbox

By signing up you agree to our Privacy Policy.


The views and opinions expressed on this website are those of the authors and do not necessarily reflect the policy or position of WatchGuard Technologies.

Stay in Touch

Recent Posts

  • Cybersecurity News: LastPass Incident Revealed, White House Issues Cybersecurity Strategy, FBI Purchases Leaked USHOR PII Data, and a Slew of Other Breaches
  • An Update on Section 230
  • Here Come The Regulations
  • US National Cybersecurity Strategy
  • Cybersecurity News: Free Cybersecurity Training, TrickBot Group Exposed, Major GoDaddy Breach, and Russia to Legalize cybercrime?!
View All

Search

Archives

Copyright © 2023 WatchGuard Technologies · Cookie Policy · Privacy Policy · Terms of Use