
How is NSA breaking so much crypto? (2015) - notRobot
https://freedom-to-tinker.com/2015/10/14/how-is-nsa-breaking-so-much-crypto/
======
hyper_reality
To summarise: the authors speculate that the NSA invested in a lot of
resources into breaking Diffie-Hellman key exchange for certain 1024-bit
primes. Just a few hardcoded 1024-bit primes were used in the majority of VPN
handshakes and a significant minority of HTTPS and SSH handshakes worldwide in
2015. This would give the NSA the ability to recover the shared symmetric key
used in these encrypted communications, and therefore decrypt them.

Since then several protocols have shifted towards preferring Elliptic Curve
Diffie-Hellman key exchange which doesn't suffer from the same attack, or at
least using larger primes for plain DHKE (1536-bit and above). However I don't
know the extent of this - a lot of VPNs at least are still using the old, weak
DH keys.

~~~
nimbius
Bingo. Garbage primes that were either pushed by NIST to vendors or bribed to
be included as default. The absolute arrogance of the authors in the Snowden
papers in detailing the leak was probably the most powerful driver of things
like dh parameters that roll every few days, and ed25519 that flat out
rejected the nsa premise that primes were at all trustworthy

Fast forward to today, and devs/cryptographers absolutely threw the nsa and
cia out on their asses for their SPECK kernel argument hinging on the
seemingly ironclad credibility of "it's classified."

Corporate players will still sneak backdoors;it's what they do. But the real
blow to the intelligence community is the loss of default trust and the active
denial by the open source community.

~~~
api
My understanding is that it wasn't that the primes were bad but that they were
hard coded, never changed, and the bit size was small enough to make attacks
based on that practical.

I'm on the fence about speck. It's so simple that there isn't much room in
there for a back door, meaning that if there is one it implies that the NSA
knows something we don't about ARX ciphers.

If the NSA knows something we dont about ARX, then could they also know
something about ChaCha?

~~~
cryptonector
Rotating DH groups periodically is difficult. SSHv2, for example, has support
for this. It takes a lot of computation to generate new groups, but then how
do the client and server agree on a group? Well, the server tells the client,
and the client has to like it -- i.e., the client has to trust the server's
group. This isn't better than just having a bigger nothing-up-my-sleeves group
to begin with.

That, ultimately, has been the solution the community landed at: nothing-up-
my-sleeve curves for ECDH and EdDSA.

The nothing-up-my-sleeve part is all about setting / agreeing to obvious and
hard guidelines for generating and selecting curves _before_ doing the
selection, then you can see that a curve was generated and selected without
any hidden agendas. We have several of these now that are generally thought to
be secure, though, of course, it's hard to say for sure. It's a pretty good
outcome.

~~~
john_alan
Ephemeral ECDH over 25519 solves all of these issues. How is it not standard.

~~~
cryptonector
Did I say it doesn't? Read carefully.

~~~
john_alan
Lol

------
ColinWright
Huge discussions from earlier submissions:

[https://news.ycombinator.com/item?id=10390822](https://news.ycombinator.com/item?id=10390822)

[https://news.ycombinator.com/item?id=13198567](https://news.ycombinator.com/item?id=13198567)

There's probably a lot of information in those discussions, but you can't
comment there, so if you have anything to add, this is the place.

------
6AA4FD
A novel (to me) thought: if we count on the government not to break our crypto
(edit: originally said break the law, I don't want to comment on the legality
of nsa actions here, it strikes me as off topic), we are already screwed. A
million other crypto discussions have surfaced: if someone wants your keys,
the can break your knees (rhymes too). If VA stops paying benefits, unless the
organization that funds and controls them steps in, a lot of people are very
screwed. While it's admirable to ensure crypto at every level (especially to
address threats from other states or private individuals), ultimately as long
as all three branches let the NSA eat our proverbial lunches and sneak under
my mattress (gag orders, huge budget, sealing court records, etc), secure
crypto is going to be a sisyphean at best. Obviously there are good reasons to
push the stone upwards, but the fitting solution to problems like infiltration
and gag orders seems like it will be a political one not a technical one.

~~~
jjoonathan
But that's just it.

1800: The right of the people to be secure in their persons, houses, papers,
and effects, against unreasonable searches and seizures, shall not be
violated, and no warrants shall issue, but upon probable cause...

2000: lol tech lets us read it all

2025: Oh no, crypto is good now? They want us to get a warrant and use non-
dragnet surveillance to pursue leads? THE HORROR!

~~~
surround
This parable from 1993 sums it up nicely.

> There was once a far away land called Ruritania, and in Ruritania there was
> a strange phenonmenon -- all the trees that grew in Ruritainia were
> transparent. Now, in the days when people had lived in mud huts, this had
> not been a problem, but now high-tech wood technology had been developed,
> and in the new age of wood, everyone in Ruritania found that their homes
> were all 100% see through...

> One day, a smart man invented paint -- and if you painted your house,
> suddenly the police couldn't watch all your actions at will...

> Indignant, the state decided to try to require that all homes have video
> cameras installed in every nook and cranny. "After all", they said, "with
> this new development crime could run rampant. Installing video cameras
> doesn't mean that the police get any new capability -- they are just keeping
> the old one." [...]

[https://cypherpunks.venona.com/date/1993/04/msg00559.html](https://cypherpunks.venona.com/date/1993/04/msg00559.html)

~~~
gorgoiler
This story didn’t make enough sense to really nail the issue. I’m surprised
this parable is popular.

Why would you build houses out of wood if the wood is transparent?

It would make more sense if it were discovered years later that the police had
special polarizing binoculars that let them see through the wood, which no one
knew they had until it was too late and all the old mud huts had been phased
out.

Also, describing someone as a “paint technologist” when they are anti-paint is
a confusing decision for a _parable_ : a story intended to make a complex
issue easier to understand. I initially assumed they were going to have a role
analogous to a cryptographer, not an anti-privacy provocateur.

Perhaps having the police attempt to foil insidious flower thieves or
dastardly rebel plots to undermine the government controlled potato cartel
would also be more in spirit with a parable. The use of awful real life crimes
(against children, even) make this a difficult one to share.

~~~
dredmorbius
Because it's cheap. Because transparency may at times be useful to the owners.
Because construction costs are lower. Because it's the fad or fashion. Because
building regulations require it. Because of convenience. Because the
transparency was an unanticipated side effect. Because it gives houses
capabilities previously unattainable. Because the wood-house vendors have
driven (by competition, monopolistic methods, patent and IP restrictions,
superior lobbying, advertising) all the mud-house vendors out of business.
Because ....

A parable is, by definition, metaphoric language. "Mud" and "wood" and "paint"
and "tranparency" are metaphors for analogue physicle vs. digital electronic
data, crypto, and surveillance.

Why do people choose, or find themselves with no alternative than digital data
systems? There are numerous reasons. Many resemble, in some fashion, the list
I've given above.

Reading parables overly literally is a category error. All metaphors melt if
pushed loudly enough.

~~~
gorgoiler
It feels like you are responding to a point I didn’t make.

It’s not so much that the metaphors break down under scrutiny, it’s that they
didn’t really make much sense to me in the first place.

------
rvnx
The way magic numbers and curves are elected is not a naive process.

The obvious backdoor in Dual EC-DRBG is a good example, and you have companies
helping the NSA in very extensive ways (e.g. Crypto AG).

It's just logic, the goal of the NSA is to protect interests of the US, if it
involves pushing rigged / weak algorithms for the greater "good" (at least
from a US perspective), they'll do it.

It's legal, and logical.

~~~
softwarejosh
Yeah logical if youre fine with degrading the US dtandards. Therell be nobody
to spy on if nobody buys our dogshit products.

~~~
rvnx
Well they are quite addictive and good products. Without SSH or TLS life would
be more sad.

~~~
espadrine
SSH is Finnish, originally; not American.

~~~
rvnx
Wow cool, I always believed (wrongly) it was US

------
phkamp
Underestimating what an organization like NSA has the resources _and_
imagination to do, is a chronic ailment.

[https://archive.fosdem.org/2014/schedule/event/nsa_operation...](https://archive.fosdem.org/2014/schedule/event/nsa_operation_orchestra/)

------
gigama
Meanwhile Barr (and predecessors) complain about sigintel "going dark" due to
encryption... always sounded like a red herring to me.

When you manage to break an encryption method you protect your zero-day
investment by encouraging everyone to continue to think you can't.

#SetecAstronomy

------
sargun
The real question I have is where is this money going? I've looked at
positions at NSA, and I know at lease one person that works there. They aren't
making heaps of money.

How are they recruiting so many qualified individuals?

~~~
cipher_314159
From what I understand: tech, mission, and tickets.

Say what you want, the NSA probably has some of the most interesting tech
problems you'll encounter. Part of that is due to the unique job that they
do-- by definition, they're doing things that nobody else in the US is allowed
to do, so they need people to solve problems that don't exist elsewhere. Part
of that is due to having a huge amassed knowledge particular to their area of
work, which allows them to work on things that other people/organizations
simply don't even know about.

Also: the NSA has supercomputers that make your eyes bleed. A buddy of mine
who worked there says that even their power bills are classified. Back in the
day, they developed a lot of highly specialized, one-of-a-kind hardware. Cray
processors had a popcount instruction that was supposedly put in place at the
NSA's behest. They can afford to get specialized treatment and demand
specialized features from folks who build their computers. If speculation
regarding their signal collection capabilities is true, then they also have to
have serious signal processing and communications tech, too.

The NSA has interesting challenges and cool tech to work with. That can
attract a LOT of people.

Another issue is mission. Look, you may not agree with the NSA's techniques
and methods. But at least the original goal of the NSA-- breaking codes used
by foreign adversaries to gain an intelligence and military advantage-- is
pretty standard military fare, and not inherently evil. SIGINT played a major
role in shortening WWII, and who knows may have happened since then (since
it's all classified). The folks I know who work there are proud of their work,
and believe they're doing the right thing. I'll note that these are GOOD
people whom I respect, which leads me to believe that the NSA isn't just
moustache-twirling and evil cackling. Some people work there because they
believe they are genuinely serving their country.

Finally: tickets. Several of the folks I know have gone to the NSA, worked
there a few years, then jumped ship to take industry jobs with clearances.
Government contractors pay a premium for cleared workers, and if you show up
with a TOP SECRET clearance in hand, your job interview chances just got
better. It's a good way to set yourself up for decent job security and
comfortable pay.

~~~
mrep
If I recall correctly, AWS will pay you an extra 10,000 a year if you have top
secret clearance.

~~~
blaser-waffle
If you're in tech, in Northern VA, and can get a TS you can angle for wayyy
more than 10k -- from AWS or others.

------
sneak
[https://github.com/caprover/caprover/issues/533](https://github.com/caprover/caprover/issues/533)

------
londons_explore
Crypto should aim to be secure for at least 100 years given current compute
performance growth. That's one human lifetime.

At no point was that true for 1024 bit DH keys.

So why did anyone ever implement it?

~~~
bostik
At a guess, it was likely a tradeoff between security and computational cost.

I used to do freelancing for an ICT magazine and in early-to-mid 00s ran some
numbers, as part of an article I did on limitations of applied cryptography.
You can't do 1024-bit math on 32-bit or even 64-bit integers. Not without
bignum libraries, which in turn make use of applied number theory. Under the
hood the multiplication of two large numbers is an O(n^2) operation.

Performing an RSA or DH calculation with decent desktop computer in ~2003 took
about 20ms with a 1024-bit number, and 80ms with a 2048-bit number. IIRC the
first was expected to be theoretically breakable in a decade or so, assuming
Moore's Law held true. The second was thought to be computationally infeasible
for at least 100 years. These days the professionally paranoid use 4096-bit
keys. (Or more recently, the nice 25519 curve which is more compact.)

So raising the security margin from "reasonable" to "paranoid", back in the
day, would have required 4x the hardware investment to serve the same amount
of traffic, and it would have imposed severe latency issues for everyone. We
also have to consider the fact that most commercial secrets have a shelf life
of years to a couple of decades. So before "E2E for everyone" became a thing,
there simply wasn't widespread interest for crypto that could protect
_personal_ secrets for a lifetime.

With regards to using cryptography for personal privacy, cypherpunks were well
ahead of their time. It's only become a mainstream issue in the last 5 years
or so.

~~~
londons_explore
Multiplying 1024 bits by 1024 bits the naive way on a 32 bit processor
involves 1024 multiply operations. Even in 2003, they were typically pipelined
with a throughput of one multiply per cycle[1], so you should be able to do
that in ~1040 clock cycles. Which is 750 _nanoseconds_ on a 1999 era Pentium
3.

Since DH key exchange isn't done on all the data, only to exchange keys, and
no machine then or now was setting up 1 million encrypted connections per
second, I don't see this as a performance bottleneck at all.

What am I missing?

[1]:
[https://books.google.co.uk/books?id=V5oACAAAQBAJ&pg=PA208](https://books.google.co.uk/books?id=V5oACAAAQBAJ&pg=PA208)

~~~
jcranmer
> Multiplying 1024 bits by 1024 bits the naive way on a 32 bit processor
> involves 1024 multiply operations.

That's 1024 32-to-64-bit wide multiply operations. On x86, where regular mul
is wide (it sets both edx and eax), that's the same as a regular operation.
Some architectures that have just a MUL and a MULH instruction would make it
two instructions. If you have neither, that would require 3 multiply
instructions plus a few shifts.

> Even in 2003, they were typically pipelined with a throughput of one
> multiply per cycle[1], so you should be able to do that in ~1040 clock
> cycles.

The inner loop is _much_ more than a wide multiply. You have to load the two
words you're multiplying (although one of them should already be loaded in the
outer loop). Then you need to two adds-with-carry, store the results back.
Next you need to handle the extra carry bit, which in the most naïve case is
another load, add-with-carry, store. And finally, you need the regular loop
management instructions.

That's 4 loads, 3 stores, 3 adds, and 1 multiply, repeated 1024 times. I don't
know the exact port availability and timing of Pentium 3 processors, but if
there's only one load /store port, and it's a 4-cycle latency operation,
you're looking at probably 25-ish cycles per inner loop iteration, or about
25,000 clock cycles.

------
javajosh
Wouldn't it be easiest to just backdoor all clients, everywhere? And ideally
you'd even do some basic threat analysis at the device to save you some
compute resources.

~~~
rvnx
You mean "Popular software XX" auto-updating ?

It's likely already operational ;)

Silent updates are extremely dangerous. This is why you can see some Israelis,
for example, refusing over-the-air updates on their phone while traveling.

~~~
AlexCoventry
Does that mean the crypto used to authenticate the updates is compromised, or
that the providers (app stores?) are? In either case, why is it safer in
Israel?

~~~
ip26
Perhaps a MITM attack by a foreign power.

------
est31
I think in the long term, we'll move away from relying on one algorithm only,
like AES or DHKE, but combine them. So for key exchange we will use DH plus
ECDH plus whatever comes out of the post quantum NIST competition, and use all
three as inputs for both parties to a KDF to produce the derived key. Attacks
against any one of the algorithms won't turn into feasible attacks onto all of
them.

~~~
arberavdullahu
Combining two algorithms is very hard and when it does it can become
insecure(new attacks can be found). Even if you can combine and its secure
then it becomes infeasible to use it often as the length of keys, IV, etc.
increases

~~~
est31
I didn't mean deep combination that changes how an algorithm works internally.
Of course that would be a stupid idea. The algorithms would still work the
same, would use separate random numbers, etc. You'd just combine them at the
integration level, treating each algorithm like a black box.

Think of two servers first doing DH and then doing ECDH. You'd get two shared
keys. This is inefficient because it has more roundtrips than doing the
algorithm's steps in parallel, but helps with understanding.

These two secrets can then serve as inputs to your KDF which derives multiple
secrets for each of the data ciphers you use. E.g. first AES with the first
secret then encrypt that with ChaCha20 with the second secret. As long as your
KDF is preimage resistant, you can't get from one algo to another.

And yes, length of keys and computation do increase. But I argue that this
will be a cost worth paying at least in some scenarios. Especially in a time
we make our CPUs slower by double digit percentages for _all_ computation in
the name of security.

------
mlcrypto
Satoshi knew to use elliptic curves in 2009 for Bitcoin. Coincidence? Also
perfect opsec and near perfect implementation...

~~~
throw9490
Every crypto geek knew to use ECC in 2009.

Hell, the Windows Genuine Advantage system, which goes back to _Windows 98SE_
, uses ECC for its keys.

[1] [https://internetcafe.ph/forum/4-lounge/17183-all-u-need-
to-k...](https://internetcafe.ph/forum/4-lounge/17183-all-u-need-to-know-
about-windows-product-key)

