4 ms·

Compared to the rest of the HN crowd, my knowledge of crypto is very light, so I could be incorrect... But aren't most widely adopted algorithms decently futur

Compared to the rest of the HN crowd, my knowledge of crypto is very light, so I could be incorrect... But aren't most widely adopted algorithms decently future proof? To where you would sort of have to break math in order for them to be crackable, if used with a very strong password? Sure, flaws were found in RSA, etc. But does something like that have a decent chance of happening again?

semiel 13y ago
"Break math" isn't quite right. You'd have to make a major mathematical advance, but there's nothing saying that's impossible.
TrainedMonkey 13y ago
Given the fact that we still following Moore's law, no crypto is future proof even if full blown quantum computation never happens. Moreover advances in Math do happen quite often, recent one is about uniformity of data after encryption functions are applied. http://news.ycombinator.com/item?id=6210852 http://news.ycombinator.com/item?id=6210852 . There was another page that showed lifetime of common ciphers, in terms of ok, partially broken, and broken, but I can't find it.
magic_haze 13y ago
Theoretically, yes. But it's far more likely that there are bugs in the implementation (both in software and hardware.) It's just a matter of time and resources to find them.
shabble 13y ago
The problem is partly that you personally aren't using just a widely adopted algorithm, you're using a specific implementation layered on some monster protocol stack with weird legacy support for "Look the other way and ROT13" mode as well as AES-$Whatever. HTTPS, for example, depends on both crypto algorithm implementation, SSL/TLS, the responsible Certificate Authority[1], your random number generator, your OS, your hardware, and, of course, much the same list for the people at the remote end. The other part of the problem is that, IIRC, the NSA is one of the largest employers of crypto/number-theoretic mathematicians, and from the article, this program with a 35k headcount probably has a bunch of them. Between them, and compute clusters not implausibly denominated in acres, a teeny tiny little flaw might be enough, if they think you deserve the effort. [1] On a tangent, has anyone explored the implications of a "give us some valid certs/signing keys for $whoever and lie to everyone who asks" NSL to one of their domestic CAs? Apart from the EFF SSL-observatory or someone else maybe noticing, of course.
- mikegioia 13y ago
  If CAs gave up valid certs/signing keys for google.com, would the fingerprint be different? And if so, would it be possible to verify the fingerprint if Google hosted it at like pki.google.com? I've been wondering if there's a public registry of certificate fingerprints somewhere to verify you're getting the cert the domain owner knows about.
  - shabble 13y ago
    Having thought about it a little bit more, I remember there are actually a few things being done about it. Certificate Pinning[1] (bundle your cert with Chrome/$browser) HSTS[2] (cache the cert you receive on this connection for $num days, bitch vocally if it changes) Convergence (Dead?) / TACK[3] (add an independent site-specific key to cross-sign the CA-provided certs, like pinning but more flexible) And the more passive detection approach I mentioned like the SSL Observatory[4] which looks for "unexpected" changes in certs. To finally answer your question, no, I don't think there is any sort of list. Doing essentially that without any centralised bookkeeping (I mean, why trust those guys any more than the CAs? Not to mention it'd be hard to scale) is the plan. DNSSec might have some sort of role in there, but I'm sufficiently hazy on how it works, and you're back to trusting your registrars/registries again anyway (see recent excitement at the NYTimes for why that's not such a great idea) [1] https://www.imperialviolet.org/2011/05/04/pinning.html https://www.imperialviolet.org/2011/05/04/pinning.html [2] https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security [3] http://tack.io/ http://tack.io/ [4] https://www.eff.org/observatory https://www.eff.org/observatory (built into HTTPS Everywhere[5] but disabled by default, IIRC) [5] https://www.eff.org/https-everywhere https://www.eff.org/https-everywhere
  - harshreality 13y ago
    They could then generate a new key for site.com, trusted by browsers that don't support cert pinning, but yes, that new key for site.com would have a different fingerprint. The only way to keep the same cert fingerprint is to get site.com's cert's private key, either by demanding it with a NSL or FISA order, or by breaking RSA (2048bit, in most cases) if the site uses RSA as almost all of them do. Generating a new cert from a trusted CA would be caught by EFF's SSL observatory (an optional feature in the HTTPS everywhere extension) and similar efforts. It would fail if used against a site that has its certificate's CA pinned in the browser, unless the NSA gets the CA private key for the right CA. Therefore, if they do have CA root key(s), they wouldn't MITM all the ssl connections they can. They would use that capability sparingly.
cheald 13y ago
An encryption algorithm's security is boolean - it either leaks data to third parties or it doesn't. The algorithms we use are currently not known to be compromised, but lack of proof of compromise is not proof of lack of compromise. If the NSA has found a vulnerability in AES-256 or some mathematical breakthrough that makes it possible to decrypt AES-256-encrypted data in polynomial time, or even just a side-channel attack in $POPULAR_SSL_LIBRARY, all bets are off.
cbhl 13y ago
> But aren't most widely adopted algorithms decently future proof? Absolutely not. The algorithms rely on assumptions, and they're not at all future-proof. One is about certain classes of mathematical problems being hard (in RSA, it's factoring numbers). We don't know whether they're hard (there's no proof; it's an "open problem"). Another is that random numbers selected in encryption are uniformly distributed and unpredictable. (In RSA, you pick two large prime numbers, p and q. If two people share a number, say my p is the same as your q, then we're both screwed. This particular assumption has been already been violated a bunch of times in the past twenty years; from the Debian OpenSSL thing, to the Android/Bitcoin thing.) There are many other assumptions (Certificate Authorities can be trusted, etc.) that a paranoid person would have to worry about. I think the new hotness is elliptic curve cryptography (e.g. ECDSA), but I don't understand it well enough to know if it's substantially better than the RSA implementations that are currently popular. I'd say what we have now is like a lock on the door -- it's enough to prevent the neighbour's kid from getting in, but not enough to stop a determined lockpick or the government.
nknighthb 13y ago
To get the regular mantra out of the way: Humans are always the weakest link. But, speaking algorithmically, it is likely you can rely on a well-vetted symmetric algorithm like AES, used conservatively according to current best practices, to keep information secret during your lifetime. Asymmetric algorithms are another matter. RSA relied on unproven assumptions that are turning out to be squishier than we might have hoped. ECC relies on assumptions that, for the moment, appear less squishy. I'm not a mathematician, so I can't have a truly informed judgement on how likely they are to remain unsquished, but the empirical history of public-key crypto means my confidence in ECC will remain well below my confidence in the likes of AES.

semiel 13y ago

"Break math" isn't quite right. You'd have to make a major mathematical advance, but there's nothing saying that's impossible.

TrainedMonkey 13y ago

Given the fact that we still following Moore's law, no crypto is future proof even if full blown quantum computation never happens. Moreover advances in Math do happen quite often, recent one is about uniformity of data after encryption functions are applied. http://news.ycombinator.com/item?id=6210852 http://news.ycombinator.com/item?id=6210852 . There was another page that showed lifetime of common ciphers, in terms of ok, partially broken, and broken, but I can't find it.

magic_haze 13y ago

Theoretically, yes. But it's far more likely that there are bugs in the implementation (both in software and hardware.) It's just a matter of time and resources to find them.

shabble 13y ago

The problem is partly that you personally aren't using just a widely adopted algorithm, you're using a specific implementation layered on some monster protocol stack with weird legacy support for "Look the other way and ROT13" mode as well as AES-$Whatever. HTTPS, for example, depends on both crypto algorithm implementation, SSL/TLS, the responsible Certificate Authority[1], your random number generator, your OS, your hardware, and, of course, much the same list for the people at the remote end. The other part of the problem is that, IIRC, the NSA is one of the largest employers of crypto/number-theoretic mathematicians, and from the article, this program with a 35k headcount probably has a bunch of them. Between them, and compute clusters not implausibly denominated in acres, a teeny tiny little flaw might be enough, if they think you deserve the effort. [1] On a tangent, has anyone explored the implications of a "give us some valid certs/signing keys for $whoever and lie to everyone who asks" NSL to one of their domestic CAs? Apart from the EFF SSL-observatory or someone else maybe noticing, of course.

mikegioia 13y ago
If CAs gave up valid certs/signing keys for google.com, would the fingerprint be different? And if so, would it be possible to verify the fingerprint if Google hosted it at like pki.google.com? I've been wondering if there's a public registry of certificate fingerprints somewhere to verify you're getting the cert the domain owner knows about.
- shabble 13y ago
  Having thought about it a little bit more, I remember there are actually a few things being done about it. Certificate Pinning[1] (bundle your cert with Chrome/$browser) HSTS[2] (cache the cert you receive on this connection for $num days, bitch vocally if it changes) Convergence (Dead?) / TACK[3] (add an independent site-specific key to cross-sign the CA-provided certs, like pinning but more flexible) And the more passive detection approach I mentioned like the SSL Observatory[4] which looks for "unexpected" changes in certs. To finally answer your question, no, I don't think there is any sort of list. Doing essentially that without any centralised bookkeeping (I mean, why trust those guys any more than the CAs? Not to mention it'd be hard to scale) is the plan. DNSSec might have some sort of role in there, but I'm sufficiently hazy on how it works, and you're back to trusting your registrars/registries again anyway (see recent excitement at the NYTimes for why that's not such a great idea) [1] https://www.imperialviolet.org/2011/05/04/pinning.html https://www.imperialviolet.org/2011/05/04/pinning.html [2] https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security [3] http://tack.io/ http://tack.io/ [4] https://www.eff.org/observatory https://www.eff.org/observatory (built into HTTPS Everywhere[5] but disabled by default, IIRC) [5] https://www.eff.org/https-everywhere https://www.eff.org/https-everywhere
- harshreality 13y ago
  They could then generate a new key for site.com, trusted by browsers that don't support cert pinning, but yes, that new key for site.com would have a different fingerprint. The only way to keep the same cert fingerprint is to get site.com's cert's private key, either by demanding it with a NSL or FISA order, or by breaking RSA (2048bit, in most cases) if the site uses RSA as almost all of them do. Generating a new cert from a trusted CA would be caught by EFF's SSL observatory (an optional feature in the HTTPS everywhere extension) and similar efforts. It would fail if used against a site that has its certificate's CA pinned in the browser, unless the NSA gets the CA private key for the right CA. Therefore, if they do have CA root key(s), they wouldn't MITM all the ssl connections they can. They would use that capability sparingly.

cheald 13y ago

An encryption algorithm's security is boolean - it either leaks data to third parties or it doesn't. The algorithms we use are currently not known to be compromised, but lack of proof of compromise is not proof of lack of compromise. If the NSA has found a vulnerability in AES-256 or some mathematical breakthrough that makes it possible to decrypt AES-256-encrypted data in polynomial time, or even just a side-channel attack in $POPULAR_SSL_LIBRARY, all bets are off.

cbhl 13y ago

> But aren't most widely adopted algorithms decently future proof? Absolutely not. The algorithms rely on assumptions, and they're not at all future-proof. One is about certain classes of mathematical problems being hard (in RSA, it's factoring numbers). We don't know whether they're hard (there's no proof; it's an "open problem"). Another is that random numbers selected in encryption are uniformly distributed and unpredictable. (In RSA, you pick two large prime numbers, p and q. If two people share a number, say my p is the same as your q, then we're both screwed. This particular assumption has been already been violated a bunch of times in the past twenty years; from the Debian OpenSSL thing, to the Android/Bitcoin thing.) There are many other assumptions (Certificate Authorities can be trusted, etc.) that a paranoid person would have to worry about. I think the new hotness is elliptic curve cryptography (e.g. ECDSA), but I don't understand it well enough to know if it's substantially better than the RSA implementations that are currently popular. I'd say what we have now is like a lock on the door -- it's enough to prevent the neighbour's kid from getting in, but not enough to stop a determined lockpick or the government.

nknighthb 13y ago

To get the regular mantra out of the way: Humans are always the weakest link. But, speaking algorithmically, it is likely you can rely on a well-vetted symmetric algorithm like AES, used conservatively according to current best practices, to keep information secret during your lifetime. Asymmetric algorithms are another matter. RSA relied on unproven assumptions that are turning out to be squishier than we might have hoped. ECC relies on assumptions that, for the moment, appear less squishy. I'm not a mathematician, so I can't have a truly informed judgement on how likely they are to remain unsquished, but the empirical history of public-key crypto means my confidence in ECC will remain well below my confidence in the likes of AES.