WhiteWinterWolf.com - encryptionhttps://www.whitewinterwolf.com/2017-12-14T00:00:00+01:00RSA key lengths, elliptic curve cryptography and quantum computing2017-12-14T00:00:00+01:002017-12-14T00:00:00+01:00WhiteWinterWolftag:www.whitewinterwolf.com,2017-12-14:/posts/2017/12/14/rsa-key-lengths-elliptic-curve-cryptography-and-quantum-computing/<p>Some tools, like <a href="/about/pgp" title="PGP keys"><span class="caps">PGP</span></a>, are still stuck<sup id="fnref-stuck"><a class="footnote-ref" href="#fn-stuck">1</a></sup> to legacy cryptography,
mainly the <span class="caps">RSA</span> algorithm.
For such tools, <span class="caps">RSA</span>-2048 is often described as strong enough for any
foreseeable future, anything above being overkill
The <a href="https://gnupg.org/faq/gnupg-faq.html#please_use_ecc" rel="external" title="GnuPG FAQ: Why do people advise against using RSA-4096?">GnuPG official documentation</a> in particular even goes
this far as considering that using <span class="caps">RSA</span>-3027 or <span class="caps">RSA</span>-4096 constitutes
<em>“an improvement so marginal that it’s really not worth mentioning”</em>, adding
that <em>“the way to go would be to switch to elliptical curve cryptography”</em>.</p>
<p>The assertion that this improvement is <em>“marginal”</em> is <a href="https://security.stackexchange.com/q/171308/32746" rel="external" title="How to interpret this statement against 4096-bit RSA (StackExchange)">debatable</a>,
as is the trust in the elliptical curves to protect us in the future.</p>
<h3><a class="toclink" href="#longer-rsa-keys">Longer <span class="caps">RSA</span> keys</a></h3>
<p>While the <abbr title="National Institute of Standards and Technology"><span class="caps">NIST</span></abbr> considers <span class="caps">RSA</span>-2048 to be safe for commercial use up to 2030,
it still advises the use of at least a <span class="caps">RSA</span>-3072 key for beyond
(see BlueKrypt’s <a href="https://www.keylength.com/en/4/" rel="external" title="NIST Recommendations (Keylength)">Keylength</a> website to get an overview of various recommendations).</p>
<p>Read quickly, such recommendation …</p><p>Some tools, like <a href="/about/pgp" title="PGP keys"><span class="caps">PGP</span></a>, are still stuck<sup id="fnref-stuck"><a class="footnote-ref" href="#fn-stuck">1</a></sup> to legacy cryptography,
mainly the <span class="caps">RSA</span> algorithm.
For such tools, <span class="caps">RSA</span>-2048 is often described as strong enough for any
foreseeable future, anything above being overkill
The <a href="https://gnupg.org/faq/gnupg-faq.html#please_use_ecc" rel="external" title="GnuPG FAQ: Why do people advise against using RSA-4096?">GnuPG official documentation</a> in particular even goes
this far as considering that using <span class="caps">RSA</span>-3027 or <span class="caps">RSA</span>-4096 constitutes
<em>“an improvement so marginal that it’s really not worth mentioning”</em>, adding
that <em>“the way to go would be to switch to elliptical curve cryptography”</em>.</p>
<p>The assertion that this improvement is <em>“marginal”</em> is <a href="https://security.stackexchange.com/q/171308/32746" rel="external" title="How to interpret this statement against 4096-bit RSA (StackExchange)">debatable</a>,
as is the trust in the elliptical curves to protect us in the future.</p>
<h3 id="longer-rsa-keys"><a class="toclink" href="#longer-rsa-keys">Longer <span class="caps">RSA</span> keys</a></h3>
<p>While the <abbr title="National Institute of Standards and Technology"><span class="caps">NIST</span></abbr> considers <span class="caps">RSA</span>-2048 to be safe for commercial use up to 2030,
it still advises the use of at least a <span class="caps">RSA</span>-3072 key for beyond
(see BlueKrypt’s <a href="https://www.keylength.com/en/4/" rel="external" title="NIST Recommendations (Keylength)">Keylength</a> website to get an overview of various recommendations).</p>
<p>Read quickly, such recommendation sounds like <span class="caps">RSA</span>-2048 should indeed be safe
for todays world.
In fact this depends on the use you intend for your keys, as “safe up to
2030” doesn’t mean that you are safe as long as you plan to migrate to
something else before 2030.
This is not some kind of end-of-support date.
This means that you must <em>assume</em> that whatever you encrypt now <em>will</em> be
decrypted in a dozen of years (and a dozen of years goes pretty fast).</p>
<p>For short term secrets or, to some extents, signature this is usually less of a problem.
The fact for instance that an attacker may be able to fake a signature from
a dozen years ago shouldn’t cause an issue: by that time such signature should
have been revoked and good software should refuse to trust keys size or
algorithms widely known as weak.</p>
<p>But for systems which may imply long-term storage or the exchange of valuable
information, then the fact that the data may be decrypted in a dozen of years
may potentially be devastating.
Concretely, if you store today an encrypted archive protected using <span class="caps">RSA</span>-2048
on a cloud service, you must assume that the content of this archive will be
known to authorities and intelligence services in a dozen of years (and, again,
time goes very fast).</p>
<p>Even if the archive file is to be quickly deleted, some intelligence agencies
attempt to process digital data exchange as a whole (the whole of Internet,
satellites, phone communications, etc.) and massively intercept and copy even
remotely potentially interesting data (an encrypted archive for instance is a perfect
candidate) to be able to analyze or decrypt them few years down the road.</p>
<p>Data acquisition and long-term storage is a major investment for some
intelligence agencies, the most widely known example being of course the <abbr title="National Security Agency"><span class="caps">NSA</span></abbr>.
A year before Snowden events, Laura Poitras published a
<a href="https://www.youtube.com/watch?v=r9-3K3rkPRE" rel="external" title="NSA Whistle-Blower Tells All: The Program | Op-Docs | The New York Times (YouTube)">short documentary</a> on William Binney,
another former <abbr title="National Security Agency"><span class="caps">NSA</span></abbr> employee.
This documentary focused on <abbr title="National Security Agency"><span class="caps">NSA</span></abbr>‘s <em>“Stellar Wind”</em> program and their
<a href="https://nsa.gov1.info/utah-data-center/" rel="external" title="Utah Data Center (Domestic Surveillance Directorate)">Utah data center</a>:</p>
<blockquote>
<p>Binney calculates the facility has the capacity to store 100 years’ worth of
the world’s electronic communications.<sup id="fnref-capacity"><a class="footnote-ref" href="#fn-capacity">2</a></sup></p>
</blockquote>
<h3 id="quantum-computing"><a class="toclink" href="#quantum-computing">Quantum computing</a></h3>
<p>The <abbr title="National Security Agency"><span class="caps">NSA</span></abbr> is a dual headed organization, with both a national intelligence and an
advisor role to protect against foreign intelligence<sup id="fnref-conflict"><a class="footnote-ref" href="#fn-conflict">3</a></sup>.</p>
<p><span class="lb-small floatright"><a href="#nsa-faq.jpg" id="nsa-faq.jpg-thumb" title="Click to enlarge"><img alt="Cover of 'Commercial National Security Algorithm Suite and Quantum Computing FAQ'" src="https://www.whitewinterwolf.com/posts/2017/12/14/rsa-key-lengths-elliptic-curve-cryptography-and-quantum-computing/nsa-faq.jpg"/></a></span>
As part of its advisor role, in January 2016 the <abbr title="National Security Agency"><span class="caps">NSA</span></abbr> wrote a very interesting <span class="caps">FAQ</span> titled
<em><a href="https://cryptome.org/2016/01/CNSA-Suite-and-Quantum-Computing-FAQ.pdf" rel="external" title="Commercial National Security Algorithm Suite and Quantum Computing FAQ (Cryptome)">Commercial National Security Algorithm Suite and Quantum Computing <span class="caps">FAQ</span></a></em>
(I highly encourage you to read it).
As soon as National Security Systems (<span class="caps">NSS</span>) are concerned, <span class="caps">RSA</span>-2048 should simply
be <em>not used anymore</em>.
This is as simple as that.
If you want to protect your data, use <span class="caps">RSA</span>-3072 minimum, this minimum being
kept relatively low for compatibility purposes but knowing that higher is better.</p>
<p>This paper then focuses on the next real threat against modern
cryptography.
According to the <abbr title="National Security Agency"><span class="caps">NSA</span></abbr>, is not the natural evolution of
processing power as it was before, but the progress toward effective quantum computing.</p>
<p>Professor <a href="https://en.wikipedia.org/wiki/Key_size#Effect_of_quantum_computing_attacks_on_key_strength" rel="external" title="Key size: Effect of quantum computing attacks on key strength (Wikipedia)">Gilles Brassard</a> explains the threat as follow:</p>
<blockquote>
<p>It takes no more time to break <span class="caps">RSA</span> on a quantum computer (up to a
multiplicative constant) than to use it legitimately on a classical computer.</p>
</blockquote>
<p>Leading the <abbr title="National Security Agency"><span class="caps">NSA</span></abbr> to conclude, in the above mentioned paper:</p>
<blockquote>
<p>A sufficiently large quantum computer, if built, would be capable of
undermining all widely-deployed public key algorithms used for key
establishment and digital signatures.</p>
</blockquote>
<p>Quantum computing would affect <span class="caps">RSA</span> and <abbr title="Elliptic Curve Cryptography"><span class="caps">ECC</span></abbr> algorithms alike, so <abbr title="Elliptic Curve Cryptography"><span class="caps">ECC</span></abbr>
is not a solution here.
However quantum computing is not some kind of magical threat affecting any kind
of encryption.
Symmetric algorithms, for instance, are said to be more resistant against
quantum computing, and new quantum resistant asymmetric algorithms proposal
have already be done.</p>
<p>According to the <abbr title="National Security Agency"><span class="caps">NSA</span></abbr>, the future in asymmetric encryption is through these
quantum resistant asymmetric algorithms, and not through <abbr title="Elliptic Curve Cryptography"><span class="caps">ECC</span></abbr>,
despite the claim in the GnuPG documentation quoted in the beginning of this article.</p>
<p>This does not mean that <abbr title="Elliptic Curve Cryptography"><span class="caps">ECC</span></abbr> is not an improvement over older algorithms such
as <span class="caps">RSA</span>: it certainly is.
This is a matter of cost: if company or a project cannot afford to implement both <abbr title="Elliptic Curve Cryptography"><span class="caps">ECC</span></abbr> and
then quantum resistant algorithms in a row, they should spare their time and money
to invest it on upcoming quantum resistant algorithms once standardization
has been achieved (a process which should take a few years).
If a project can afford both then its obviously better.
But one should not rush now on <abbr title="Elliptic Curve Cryptography"><span class="caps">ECC</span></abbr> just to find themselves unable to proceed
with quantum resistant algorithms down the road.</p>
<p><abbr title="Elliptic Curve Cryptography"><span class="caps">ECC</span></abbr> algorithms were an answer to the increase in computational power, but as
the threat shifts the answer has to shift too.</p>
<div class="admonition note">
<p class="admonition-title">Note</p>
<p>One the advantages of <abbr title="Elliptic Curve Cryptography"><span class="caps">ECC</span></abbr> algorithms is a return to relatively small key
size (a 256 <abbr title="Elliptic Curve Cryptography"><span class="caps">ECC</span></abbr> key providing the same strength as a 3072 bits <span class="caps">RSA</span> key).</p>
<p>According to this <abbr title="National Security Agency"><span class="caps">NSA</span></abbr> paper, this won’t be the case anymore with quantum
resistant algorithms as:</p>
<blockquote>
<p>The key sizes for these algorithms will be much larger than those used
in current algorithms.</p>
</blockquote>
<p>Because of this, the <abbr title="National Security Agency"><span class="caps">NSA</span></abbr> also calls interested parties to measure potential
side-effects before-hand:</p>
<blockquote>
<p>Work will be required to gauge the effects of these larger key sizes on
standard protocols as well.
<abbr title="National Security Agency"><span class="caps">NSA</span></abbr> encourages those interested to engage with standards organizations
working in this area and to analyze the effects of adopting quantum
resistant algorithms in standard protocols.</p>
</blockquote>
</div>
<h3 id="non-standard-key-lengths-and-algorithms"><a class="toclink" href="#non-standard-key-lengths-and-algorithms">Non-standard key lengths and algorithms</a></h3>
<p>From time to time I encounter people advocating the use of
non-standard algorithms or of standard algorithms used in non-standard or
unusual ways:</p>
<ul>
<li>New algorithms which didn’t went through the same amount of scrutiny as the
standardized ones.</li>
<li>Non-standard algorithm combination or usage.</li>
<li>Uncommon key sizes.</li>
</ul>
<p>Cryptography is a very complex and sensitive matter, it should go without
saying none of these practices should be considered in the realm of any real
security scheme.</p>
<ul>
<li>
<p><a href="https://www.schneier.com/blog/archives/2011/04/schneiers_law.html" rel="external" title="Schneier's Law (Schneier)">Schneier’s law</a> says that you should not run your own crypto
(this is discussed more in depth <a href="https://security.stackexchange.com/q/18197/32746" rel="external" title="Why shouldn't we roll our own? (StackExchange)">here</a>), this also apply in
choosing obscure algorithms which weren’t vetted by the cryptographers
community just because you somehow made a wrong relation between
<em>less known</em> and <em>more secure</em>.</p>
</li>
<li>
<p>Cryptographic algorithms are designed to be used a certain way, and they
will deliver the highest security when they are used exactly this way.
As soon as you start to deviate from this way, even “just a little”, you
must assume that you <em>reduce</em> the resulting security.</p>
<p>The most perfect example is hashing algorithms: I regularly see misinformed
people re-hashing something several times “to increase security”, while
for several reasons hashing a hash will in fact decrease the resulting security.</p>
</li>
<li>
<p>Even if an algorithm may theoretically designed to work with an arbitrary
key size, once the community agreed on a common set of sizes it is usually
unwise to settle apart.</p>
<p>Every software and devices being tested with those sizes, using uncommon key
sizes puts you out of usual test-cases and may raise unexpected behaviors.
In the best case, this will be an error message.
In the worst case, this will be a weakness affecting the resulting security.</p>
<p>As with the first bullet, such practice comes from a frequent misconception
that what is uncommon is more secure.
Advocates of such measure usually explain that, assuming that a state actor
is able to break 4096-<span class="caps">RSA</span>, they would require specific optimization
which won’t work against, say, a 3456 bits key which would require specific
development to be broken.</p>
<p>To leave the assumptions realms and go back to Earth, I’ve never
encountered any report stating that a 120 bits key is harder to break than
a 128 bits one.
So if an attacker is able to break <span class="caps">RSA</span> keys up to 4096 bits, then a 3456
bits key will be broken too.</p>
<p>Uncommon key sizes exposes you to software bugs and interoperability issues
without any real security gain.</p>
</li>
</ul>
<div class="footnote">
<hr/>
<ol>
<li id="fn-stuck">
<p>The use of <abbr title="Elliptic Curve Cryptography"><span class="caps">ECC</span></abbr> in <span class="caps">PGP</span> tools has been standardized by the <a href="https://tools.ietf.org/html/rfc6637" rel="external" title="RFC 6637: Elliptic Curve Cryptography (ECC) in OpenPGP (IETF)"><span class="caps">RFC</span> 6637</a>
in 2012.
GnuPG added it in <a href="https://wiki.gnupg.org/ECC" rel="external" title="GnuPG ECC support (GnuPG wiki)"><span class="caps">GPG</span> 2.1</a> released in 2014, turning into stable in
<a href="https://lists.gnupg.org/pipermail/gnupg-announce/2017q3/000413.html" rel="external" title="Announce: GnuPG 2.2.0 released (GnuPG mailing list)"><span class="caps">GPG</span> 2.2</a> in August 2017. <a class="footnote-backref" href="#fnref-stuck" title="Jump back to footnote 1 in the text">↩</a></p>
</li>
<li id="fn-capacity">
<p>I saw several websites trying to estimate the storage space
required or available in such facility in regards to cost, often ending
with astronomical numbers.
The fact is that you don’t need this facility to be able to store 100 years
worth of communication right from the beginning, this would be plain dumb.
You need to be able to store one or just a few years, and simply
ensure that the storage capacity grows at a sufficient pace compared to the
quantity of incoming intercepted data, either by adding new storage units
over the years or replacing existing ones to take advantage of the constant
technological evolution.
You don’t need storage <em>capacity</em>, you need storage <em>scalability</em>, and the
<abbr title="National Security Agency"><span class="caps">NSA</span></abbr> itself <a href="https://nsa.gov1.info/utah-data-center/" rel="external" title="Utah data center (Domestic Surveillance Directorate)">doesn’t say anything different</a>:</p>
<blockquote>
<p><span class="dquo">“</span>The Utah Data Center was built with future expansion in mind and the ultimate capacity will definitely be “alottabytes”!</p>
</blockquote>
<p><a class="footnote-backref" href="#fnref-capacity" title="Jump back to footnote 2 in the text">↩</a></p>
</li>
<li id="fn-conflict">
<p>Of course these two roles don’t go without a certain amount of
conflict of interests, as shown in <a href="https://en.wikipedia.org/wiki/Dual_EC_DRBG#Security" rel="external" title="Dual_EC_DRBG: Security"><abbr title="Dual Elliptic Curve Deterministic Random Bit Generator">Dual_EC_DRBG</abbr> case</a>. <a class="footnote-backref" href="#fnref-conflict" title="Jump back to footnote 3 in the text">↩</a></p>
</li>
</ol>
</div>What is the difference between HTTP and HTTPS with a self-signed certificate?2015-08-28T00:00:00+02:002015-08-28T00:00:00+02:00WhiteWinterWolftag:www.whitewinterwolf.com,2015-08-28:/posts/2015/08/28/what-is-the-difference-between-http-and-https-with-a-self-signed-certificate/<h3>Security difference</h3>
<p>First, let’s talk about <span class="caps">SSL</span> (now called <span class="caps">TLS</span> by the way), which adds the ‘S’ at
the end of <span class="caps">HTTP</span><strong>S</strong> and is in charge of “<em>securing the communication</em>“.
The clue to answer this question is indeed to fully understand what we mean by
“securing the communication”.</p>
<p><span class="caps">SSL</span>, no matter if it is a self-signed certificate which is being used or one
signed by a trusted <span class="caps">CA</span>, will ensure that the communication between you and the
remote host remains confidential and that no one can tamper with any data exchanged.</p>
<p>The warning message shown by browser about self-signed certificates is
therefore not about that.</p>
<p>But, how can you be <em>sure</em> that the remote host answering to your requests is
really the one you expect?
With public websites, for which you have no direct way to authenticate the
certificate by yourself, this is just impossible.
Here comes external …</p><h3 id="security-difference"><a class="toclink" href="#security-difference">Security difference</a></h3>
<p>First, let’s talk about <span class="caps">SSL</span> (now called <span class="caps">TLS</span> by the way), which adds the ‘S’ at
the end of <span class="caps">HTTP</span><strong>S</strong> and is in charge of “<em>securing the communication</em>“.
The clue to answer this question is indeed to fully understand what we mean by
“securing the communication”.</p>
<p><span class="caps">SSL</span>, no matter if it is a self-signed certificate which is being used or one
signed by a trusted <span class="caps">CA</span>, will ensure that the communication between you and the
remote host remains confidential and that no one can tamper with any data exchanged.</p>
<p>The warning message shown by browser about self-signed certificates is
therefore not about that.</p>
<p>But, how can you be <em>sure</em> that the remote host answering to your requests is
really the one you expect?
With public websites, for which you have no direct way to authenticate the
certificate by yourself, this is just impossible.
Here comes external trusted <span class="caps">CA</span>: by trusting a <span class="caps">CA</span> you assume that all
certificates signed by him are used only for legit purposes to secure the
traffic with the server(s) explicitly mentioned in the certificate.</p>
<p>This is all this warning is about: your browser warns you that, while the
communication with the remote host is secured, it has no automated way to
authenticate the certificate (and therefore the remote host identity) and
relies on you to explicitly accept or refuse to establish the connection.</p>
<p>If the self-signed certificate is associated to one of your servers, you should
be able to proceed with this manual verification: you should be able to check
the certificate fingerprint, or at least you should know if the certificate has
been changed recently or not.</p>
<p>Once this manual verification has been done, your browser offers you the
possibility to “remember” this certificate: this means that the browser will
associate this self-signed certificate to this <span class="caps">URL</span> and provide no warning in
the future since, now, the browser has an automated way to authenticate the certificate.</p>
<p>However, as soon as the self-signed certificate will be changed on the server,
the browser will display the warning again, and it will again be up to the
end-user to determine wether this certificate change is normal and if the new
certificate presented by the server is indeed a genuine one.</p>
<h3 id="user-experience-difference"><a class="toclink" href="#user-experience-difference">User experience difference</a></h3>
<p><span class="caps">IMHO</span> the default way browsers inform the user’s about current security is
mostly ineffective.
Users just <a href="https://ux.stackexchange.com/questions/43295/do-users-care-about-https" rel="external">do not care about the padlock</a>, and
<a href="http://commerce.net/wp-content/uploads/2012/04/The%20Emperors_New_Security_Indicators.pdf" rel="external">do not notice when the <span class="caps">SSL</span> security is missing</a>.
Even users who care haven’t access to the right information (nothing prevents a
website showing an <a href="https://en.wikipedia.org/wiki/Extended_Validation_Certificate" rel="external">Extended Validation Certificate</a> to configure their
website to use poor and weak cryptography systems or to rely on less secured
third-party content: default browser’s interface will still be happy about that
and show the “top-notch security” green bar).</p>
<p>Hopefully, depending on the browser used there might be some plugins trying to
remedy this situation.
On Firefox, you have <a href="https://addons.mozilla.org/en-US/firefox/addon/ssleuth/" rel="external">SSLeuth</a> which will by default add a new notification
area to the left or the <span class="caps">URL</span> bar (next to the padlock when there is one)</p>
<p>This new notification area has the following properties:</p>
<ul>
<li>
<p>The background color ranges from red (no security: <span class="caps">HTTP</span>), through orange
(poor security setup) to blue and green (good and best security according
to current best-practices).</p>
</li>
<li>
<p>An option allows to extend this color to the whole <span class="caps">URL</span> bar, so <span class="caps">HTTP</span>
websites will now display a fully red <span class="caps">URL</span> bar,</p>
</li>
<li>
<p>At last a score (between 0 and 10) is displayed to show an estimation of
the current <span class="caps">SSL</span>/<span class="caps">TLS</span> security level. It takes into account several criterion,
amongst them the type of certificate (self-signed, <span class="caps">CA</span> signed, Extended
Validation Certificate), the cryptographic configuration used, third-party
content security, etc. Clicking on the notification area provides all score
details, mostly useful when the result is not the expected one
(aka “<em>Why is my bank website granted an orange <span class="caps">URL</span> bar?</em>“).</p>
</li>
</ul>
<hr/>
<p class="footnote">Article based on a <a href="https://security.stackexchange.com/q/98006/32746#98014" rel="external">StackExchange answer</a>.</p>