TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

The Factoring Dead: Preparing for the Cryptopocalypse

168 pointsby oracukalmost 12 years ago

15 comments

rdlalmost 12 years ago
Pluggable crypto algorithms are one of the reasons for a lot of protocols being overly baroque and thus vulnerable (due to implementation flaws), or at least not widely used. This all started due to the export controls in the 1990s -- when you needed to have a US&#x2F;non-US version anyway, you could then do 10 algorithms. But, if you don&#x27;t have that concern anymore, it&#x27;s senseless complexity.<p>IMO the best way to do all of this is to have one (set of) algorithm per major version of protocol. It&#x27;s fine to change that (by adding new protocol handling) going forward, and potentially to deprecate old versions too, but cipher negotiation&#x2F;etc. is otherwise madness-making. That, and shitty encodings, are most of the pain I have when working with stuff.<p>(The issue raised here of &quot;ECC should be more widely used&quot; is good, though -- I&#x27;ve been looking at blinded ECC algorithms recently.)
评论 #6156196 未加载
评论 #6156407 未加载
tptacekalmost 12 years ago
My name is on this talk, but you should know: not only did I not go to Black Hat to help deliver the talk, but I did zero work on its preparation; this is Javed Samuel and Tom Ritter&#x27;s talk all the way.<p>How my name came to be on it is a long, boring story.
评论 #6156183 未加载
评论 #6156980 未加载
milkshakesalmost 12 years ago
pdf (who disables save anyway?): <a href="https://media.blackhat.com/us-13/us-13-Stamos-The-Factoring-Dead.pdf" rel="nofollow">https:&#x2F;&#x2F;media.blackhat.com&#x2F;us-13&#x2F;us-13-Stamos-The-Factoring-...</a>
delinkaalmost 12 years ago
&quot;Most systems are not designed for cryptographic agility&quot; but even if they were, that&#x27;s yet another vector for attack. If your software is configurable in some way around cryptography (new algorithms in a shared library, new configuration files describing padding or negotiation methods), the the attacker just has to reconfigure your device. When you distribute those changes, they have to be signed; with a configuration currently supported by the app; which probably involves the weak or broken algorithm you&#x27;re trying to replace.<p>The Problem® as I see it is one of computational power. Everyone carries mobile devices. Everyone expects their mobile devices to be secure. But everyone appears to be more interested in the perceived speed of their devices. How do we make most algorithms more secure? Larger keys, or some other form of increased work for attackers. That slows down smartphones and now people are having a Bad User Experience™ and well, we can&#x27;t have that.<p>It seems like every time someone makes security more user-friendly, they necessarily introduce weaknesses into the entire system. I gave up on trying to solve these kinds of problems long ago when I realized I was terrible at it.
评论 #6156212 未加载
VLMalmost 12 years ago
An interesting analogy is post-quantum cryptography which gets to more or less the same place (can&#x27;t depend on factoring being hard) by somewhat different path.<p>There&#x27;s a nice wikipedia category for post quantum crypto.<p><a href="http://en.wikipedia.org/wiki/Category:Post-quantum_cryptography" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Category:Post-quantum_cryptogra...</a><p>The slideshow (which I paged thru pretty quickly) seemed to be a good general coverage of the whole situation, followed by great detail of exactly precisely one solution, ECC. There&#x27;s lattice, hash, and multivariate. That&#x27;s too bad that the slides were so general and then suddenly laser focused. I realize there&#x27;s time limits, etc.<p>There are also system based issues. What I mean is, lets say you decide to implement a signing only hash algo as a &quot;replacement&quot; for a pure encryption algo which is now magically broken. Well that requires major system changes to move from an encryption system to a signing system to accomplish the same meat-level goal. Its not as simple as search and replace library names. Which is an example of the old saying that crypto is hard.
评论 #6155923 未加载
beagle3almost 12 years ago
Question for the practitioners: is there a hardware token like the yubikey neo, Openpgp card, gemalto.net etc that can do ECC signing or encryption? In some countries, fips140 hardware is required for legal filings, but I&#x27;ve only found RSA tokens.
pbsdalmost 12 years ago
I agree with pushing elliptic curves, but I don&#x27;t like the way they get there.<p>First, some historical corrections: the first L[1&#x2F;2] algorithm for either factorization or discrete log was CFRAC, presented by Brillhart and Morrison in 1974 [1]. This was the first time a L[1&#x2F;2] algorithm was <i>formalized</i>: descriptions of this basic method go back to the 1930s and the work of Lehmer and Powers [2] and Kraitchik. I presume 1979 refers to Adleman&#x27;s subexponential discrete log paper [3].<p>1984 saw Coppersmith&#x27;s L[1&#x2F;3] algorithm for discrete logarithms in GF(2^n) [4]. The trick was that, in GF(2^n), the freshman&#x27;s dream is true: A^2 + B^2 = (A + B)^2. This makes the polynomials we need to check for smoothness much smaller (for appropriately chosen polynomials), so much so that the overall asymptotic running time decreases.<p>Then in 1990 the number field sieve [5] appears for factorization, also at L[1&#x2F;3]. You&#x27;d think that this had something to do with 1984&#x27;s Coppersmith, right? Wrong. The number field sieve came from independent efforts, started by ElGamal [6], Coppersmith et al [7], and Pollard [8].<p>So you can see that Coppersmith&#x27;s GF(2^n) trick never factored into the number field sieve. The function field sieve [9] is, however, a continuation of Coppersmith&#x27;s effort in fields of small characteristic (e.g., GF(2^n), GF(3^n), etc). There are many improvements over the FFS that I&#x27;m going to gloss over now. More recently, this work has been continued by Joux and friends [10,11,12,13], who have basically annihilated sieving for some specific fields, and most of the time is spent on individual logs. Note that even for small characteristic, where such algorithms apply, well-chosen fields will still be fairly secure: for example GF(2^2039) still has about 77 bits of security, similar to RSA-1024.<p>There is no reason to believe that the tricks used by Joux carry over to the integers or GF(p), as the 1984 trick never carried over either. We might see an improvement to integer factorization soon, but I seriously doubt these tricks will be in its origin. My <i>guess</i> is that RSA will get an long overdrawn death like Rivest&#x27;s other brainchild, RC4.<p>There are plenty of reasons to prefer elliptic curves over finite fields. Elliptic curves are smaller, faster, safer, and shinier. But like the finite field case, there are also classes of curves that are cheaper to attack. Did you know that <i>all</i> elliptic curves over GF(2^n) can be solved in subexponential time [14]? Let&#x27;s move to NTRU! This kind of scare tactics is unproductive.<p>[1] <a href="http://www.ams.org/journals/mcom/1975-29-129/S0025-5718-1975-0371800-5/S0025-5718-1975-0371800-5.pdf" rel="nofollow">http:&#x2F;&#x2F;www.ams.org&#x2F;journals&#x2F;mcom&#x2F;1975-29-129&#x2F;S0025-5718-1975...</a><p>[2] <a href="http://www.ams.org/journals/bull/1931-37-10/S0002-9904-1931-05271-X/S0002-9904-1931-05271-X.pdf" rel="nofollow">http:&#x2F;&#x2F;www.ams.org&#x2F;journals&#x2F;bull&#x2F;1931-37-10&#x2F;S0002-9904-1931-...</a><p>[3] <a href="http://cr.yp.to/bib/1979/adleman.html" rel="nofollow">http:&#x2F;&#x2F;cr.yp.to&#x2F;bib&#x2F;1979&#x2F;adleman.html</a><p>[4] <a href="http://www.enseignement.polytechnique.fr/profs/informatique/Francois.Morain/Master1/Crypto/projects/Coppersmith84.pdf" rel="nofollow">http:&#x2F;&#x2F;www.enseignement.polytechnique.fr&#x2F;profs&#x2F;informatique&#x2F;...</a><p>[5] <a href="http://www.iai.uni-bonn.de/~adrian/nfs/lenstra90number.pdf" rel="nofollow">http:&#x2F;&#x2F;www.iai.uni-bonn.de&#x2F;~adrian&#x2F;nfs&#x2F;lenstra90number.pdf</a><p>[6] <a href="http://link.springer.com/chapter/10.1007%2F978-1-4684-4730-9_22" rel="nofollow">http:&#x2F;&#x2F;link.springer.com&#x2F;chapter&#x2F;10.1007%2F978-1-4684-4730-9...</a><p>[7] <a href="http://cr.yp.to/bib/1986/coppersmith.html" rel="nofollow">http:&#x2F;&#x2F;cr.yp.to&#x2F;bib&#x2F;1986&#x2F;coppersmith.html</a><p>[8] <a href="http://link.springer.com/content/pdf/10.1007/BFb0091536.pdf" rel="nofollow">http:&#x2F;&#x2F;link.springer.com&#x2F;content&#x2F;pdf&#x2F;10.1007&#x2F;BFb0091536.pdf</a><p>[9] <a href="http://cr.yp.to/bib/1994/adleman-ffs.html" rel="nofollow">http:&#x2F;&#x2F;cr.yp.to&#x2F;bib&#x2F;1994&#x2F;adleman-ffs.html</a><p>[10] <a href="http://eprint.iacr.org/2012/720" rel="nofollow">http:&#x2F;&#x2F;eprint.iacr.org&#x2F;2012&#x2F;720</a><p>[11] <a href="http://eprint.iacr.org/2013/074" rel="nofollow">http:&#x2F;&#x2F;eprint.iacr.org&#x2F;2013&#x2F;074</a><p>[12] <a href="http://eprint.iacr.org/2013/095" rel="nofollow">http:&#x2F;&#x2F;eprint.iacr.org&#x2F;2013&#x2F;095</a><p>[13] <a href="http://eprint.iacr.org/2013/400" rel="nofollow">http:&#x2F;&#x2F;eprint.iacr.org&#x2F;2013&#x2F;400</a><p>[14] <a href="http://eprint.iacr.org/2012/146" rel="nofollow">http:&#x2F;&#x2F;eprint.iacr.org&#x2F;2012&#x2F;146</a>
评论 #6157313 未加载
utungaalmost 12 years ago
Does this help to explain xKeyScore?<p>If there have been major mathematical advances in the last 6 months what is the chance that mathematicians at NSA made those advances 2 years ago and didn&#x27;t reveal? (How many good mathematicians know colleagues who &#x27;dissapeared&#x27; into a career for the spooks, I certainly know of some). If so , what&#x27;s the chance that somewhere in the billion dollar budgets they found enough money to turn advances into practical attacks? And <i>if</i> such practical attacks exist, wouldn&#x27;t that have made it possible to turn a network level tap (such as has been revealed) into a usable &#x27;full take&#x27; system that bypasses the &#x27;going dark&#x27; problem... given prevalence of RSA based approaches to cryptography on the net today.
aglalmost 12 years ago
The slide deck has an impressive list of authors, but slide 55 (about TLS and ECC) appears to be misleading without the context of the talk itself.<p>I didn&#x27;t see the talk, so I don&#x27;t know what they were aiming at, but ECC works the same in TLS 1.0, 1.1 and 1.2. Hybrid chains (i.e. an ECDSA public key in a certificate, signed by an RSA certificate) work fine too.<p>(Not all implementations of TLS support ECC of course.)
评论 #6156176 未加载
评论 #6155913 未加载
kybernetikosalmost 12 years ago
I learnt a little about ECC to make my bitcoin-key-for-encryption-gravatar-as-key-server proof of concept <a href="http://kybernetikos.github.io/VisualSecrecy/" rel="nofollow">http:&#x2F;&#x2F;kybernetikos.github.io&#x2F;VisualSecrecy&#x2F;</a><p>I really love the way that you can visualise what is actually going on by drawing lines on a graph. Factoring is much less visual for me. It just seems very fun that you have a private factor, a public point and, when doing encryption, you have a shared point which is a literal point on a curve.
blumentopfalmost 12 years ago
Regarding DNSSEC, it should be noted that ECDSA was specified in April 2012 (RFC 6605) and resolver support started with Unbound 1.4.17 (May 2012) and BIND 9.9.2 (Oct 2012). So this was very recent and the percentage of resolvers on the Internet which have already upgraded to an ECDSA-enabled release is so small that it is absolutely pointless to use ECDSA with DNSSEC now. Most of the resolvers won&#x27;t recognize the algorithm and will treat the zone contents as unsigned.<p>Regarding OpenSSL, I tested ECC with S&#x2F;MIME in 2009 and it turned out to be unsupported. Just tried it again with 1.0.1e and it&#x27;s still not supported. It works for TLS but the problem is that vendors ship outdated releases: Debian stable comes with 1.0.1 which is good, RHEL comes with 1.0.0 which is not so good (no TLS 1.2), SLES comes with 0.9.8j (even in the recently release SLES 11 SP3) which is very bad.<p>So support for ECC is still very disappointing and far away from being usable in production.
wbhartalmost 12 years ago
The argument here is approximately this: as solving jigsaw puzzles has been dramatically improved recently, you never know, maybe manufacture of weapons of mass destruction will suddenly get really easy overnight, resulting in an apocalypse.<p>What Joux and others have done is both important and impressive. But it simply isn&#x27;t the same as breaking secure cryptosystems. The analogy between the two is simply overplayed.<p>Did people have reason to believe that the systems Joux and co. can crack were hard? No, despite not knowing how to crack them. Do people believe that their more secure cousins are hard? Yes, they do.
评论 #6156185 未加载
ds9almost 12 years ago
Kinda late here, and unqualified to comment on math - just wanted to mention, in case ECC and the others eventually are compromised - there is something to fall back on. The &quot;one time pad&quot; method &quot;has been proven to be impossible to crack if used correctly&quot; (<a href="https://en.wikipedia.org/wiki/One-time_pad" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;One-time_pad</a>). Given a side channel that&#x27;s secure for the purpose, I expect there could be a software implementation that would be usable indefinitely.
评论 #6158264 未加载
评论 #6158824 未加载
评论 #6158032 未加载
beagle3almost 12 years ago
Question for those in the know: have there been any advances on DLP in galois fields generated by primitive polynomials?
helmut_hedalmost 12 years ago
Slide 5. Why can no one spell &quot;Appelbaum&quot;?