
Mythology About Security - dsr_
https://gettys.wordpress.com/2018/04/09/mythology-about-security/
======
collinmanderson
> We asked MIT whether we could incorporate Kerberos (and other encryption)
> into the X Window System. According to the advice at the time (and MIT’s
> lawyers were expert in export control, and later involved in PGP), if we had
> even incorporated strong crypto for authentication into our sources, this
> would have put the distribution under export control, and that that would
> have defeated X’s easy distribution.

Fascinating.

~~~
GuB-42
Did they really have to include strong crypto?

Most secure protocols negotiate a cipher suite. They just had to add the
ability to do so, and maybe some placeholder algorithm using the maximum
allowed strength at the time.

~~~
wmf
The flip side is: Just imagine if Kerberos 1.0 with 40-bit DES was baked into
X11 or even IPv4. We'd _still_ be fighting those downgrade attacks. Or maybe
we'd be layering real encryption over the broken-but-unremovable encryption,
with all the overhead that entails.

~~~
sk5t
Why do you think that is true? Cipher suite selection and whitelisting is not
a new thing--even if plaintext with CRC32 is in the mix--we deal with it
successfully enough in TLS and SSH all the time.

~~~
ayrx
“we deal with it successfully enough in TLS and SSH all the time”

Not quite. Downgrade attacks has been a huge problem for TLS.

------
colorincorrect
I often hear that (quote the article) "Government export controls crippled
Internet security and the design of Internet protocols from the very
beginning"

Can anyone give me examples of which a design flaw in the protocol results
directly in poorer security, and how it could have been better designed?

Not that I doubt the claim but I am not literate in this area.

~~~
stordoff
[https://en.wikipedia.org/wiki/Export_of_cryptography_from_th...](https://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States)
is probably a good place to start.

One fairly concrete example:

> Shortly afterward, Netscape's SSL technology was widely adopted as a method
> for protecting credit card transactions using public key cryptography.
> Netscape developed two versions of its web browser. The "U.S. edition"
> supported full size (typically 1024-bit or larger) RSA public keys in
> combination with full size symmetric keys (secret keys) (128-bit RC4 or 3DES
> in SSL 3.0 and TLS 1.0). The "International Edition" had its effective key
> lengths reduced to 512 bits and 40 bits respectively (RSA_EXPORT with 40-bit
> RC2 or RC4 in SSL 2.0, SSL 3.0 and TLS 1.0), by zero-padding 88 bits of the
> normal 128-bit symmetric key. Acquiring the 'U.S. domestic' version turned
> out to be sufficient hassle that most computer users, even in the U.S.,
> ended up with the 'International' version, whose weak 40-bit encryption
> could be broken in a matter of days using a single computer. A similar
> situation occurred with Lotus Notes for the same reasons.

It's not necessarily a design flaw in the protocol, but it has basically the
same effect.

------
mashedvikings
"Often hear that the reason today’s Internet is not more secure is that the
early designers failed to imagine that security could ever matter."

Related to this, you should definitely watch Moxie Marlinspike's (lead dev of
Signal) talk where he tells about his discussion with Kipp Hickman, a
developer of SSL:
[https://www.youtube.com/watch?v=UawS3_iuHoA#t=13m52s](https://www.youtube.com/watch?v=UawS3_iuHoA#t=13m52s)
(until 16:33)

------
adynatos
this is why openbsd foundation is based in canada.

------
euske
Does this matter? We (not just IT people, everyone in the world) always lack
the imagination of what could happen, and every time we're caught off guard by
the creativity of malicious people. Sometimes a government is to blame, but
eventually it's just us. Again, security is a process and a never-ending game
of arms race. When you stop playing, they'll get the best of you.

(Disclaimer: this is for the sake of argument. I'm actually a laid-back person
and against government surveillance and stuff.)

~~~
lordofmoria
I would argue that usually it doesn’t matter because of the reasons you
mentioned, but in this particular case it really did. The US government, and
the NSA in particular, made it a matter of explicit policy to delay and
discourage commercial crypto research and development in the US. Off hand, I’d
guess this delayed crypto by 10 years. Imagine if 10 years ago, we had today’s
understanding of crypto. I’d wager TLS would look better.

I’ve been reading Crypto by Steven Levy, it’s on exactly this topic, and I’m
astounded by how actively the NSA discouraged commercial research, and how
early on it happened: mid-1970s.

~~~
mashedvikings
One of the greatest heroes we have to thank are Diffie and Hellman who put up
a fight when US government went against their research on public key
cryptography.

But I suppose the reason NSA was delaying was they had to develop a workaround
for the encryption. Remember, while public key crypto got strong in 1996 when
the key lengths ended Tailored Access Operations (NSA's hacking team) was
created in 1998, before DES was replaced with AES in 2001.

Now obviously it's not that simple. Phasing out weak standards has taken very
long. Personally, I would love to understand what goes on in the heads of
developers who still use age old primitives like MD5 and RSA-1280 (iMessage).

~~~
acqq
> I suppose the reason NSA was delaying was they had to develop a workaround
> for the encryption

No. Their primary purpose was never to protect anybody else but their own
operations (the concept "Nobody but us" is older and broader than Wikipedia
currently knows
[https://en.wikipedia.org/wiki/NOBUS](https://en.wikipedia.org/wiki/NOBUS) )
especially not "common citizens". The NSA is mainly a _military_ institution.
Had they been able to get by with nobody being allowed to use crypto but they,
they would have done that and continue doing.

Bonus: this is directly from the NSA:

[https://www.nsa.gov/resources/everyone/digital-media-
center/...](https://www.nsa.gov/resources/everyone/digital-media-
center/publications/cryptokids/assets/files/ck-bio-sam.pdf)

Covered here:

[https://www.dailydot.com/layer8/cryptokids-nsa-
foia/](https://www.dailydot.com/layer8/cryptokids-nsa-foia/)

------
petermcneeley
"The choice for all of us working on that software was stark: we could either
distribute the product of our work, or enter a legal morass, and getting it
wrong could end up in court"

Is this not simply an economically expedient choice? To put the security and
privacy of users below that of product distribution? How is this choice really
different than any tradeoff a software company today makes about security?

~~~
bostik
That's an unfair characterisation.

There's a world of difference between choosing not to implement security
features to allow faster shipping; and keeping security features out because
with them you are not _allowed_ to ship.

The first is garden-variety negligence. The second is politically mandated
malfeasance.

------
mikeash
I find this hard to believe. I can certainly believe that American crypto laws
resulted in a lot of unencrypted protocols, but there’s more to security than
just crypto. What about things like rlogin? A lot of older stuff (and newer
stuff, for that matter) assumes that the other side is trustworthy, which is a
separate concern from encryption.

~~~
testvox
What about rlogin? Isn't the major security vulnerability with it the lack of
encryption?

~~~
mikeash
One of rlogin's authentication methods is to have a list of hosts and
usernames that are allowed to log in. If you're on the list, you're in. How
does it know you're actually using that username? Well, it asks your host,
which would definitely never lie.

------
Asiasweatworker
This make me to recall a website which claimed NIST P256 ECC Curve is unsafe
in some respects.

------
manhnt
Can someone explain the US laws of export control around cryptography in
layman's term?

~~~
digi_owl
Best i recall, from back when the PGP thing was going down, was that anything
above 90-bit keys (or some such) was basically considered the equivalent of a
military weapon.

So if you wanted to offer it to anyone outside of USA, you were treated as if
you were trying to deal in tanks or fighter jets.

------
bitwize
So uh, why did you design X in such a manner that any client could sniff any
other client's events and windows by default, and only later add a (quite
inadequate) SECURITY extension?

This is what we mean when we say that the security model of X is obsolete, and
an afterthought besides. The threat model was completely different back then:
every griefer, troll, thief, and state actor didn't have a pipe straight into
your X session through the browser, and for the most part X was used to talk
to trusted programs on trusted hosts.

Wayland, by contrast, has a security model for the modern, hostile internet
built in from the start.

~~~
educar
> Wayland, by contrast, has a security model for the modern, hostile internet
> built in from the start.

And yet basic video and screen capture is not working for years now. Arbitrary
rectangle capture still doesn't work on Ubuntu 16.04 in any tool I know of.

So they made it so secure to make basic features not work.

~~~
Valmar
I wonder if there will be a successor to Wayland and X11 that learns from the
mistakes of both?

Can't always make wise improvements if you don't first make awful mistakes
that weren't properly considered in practice.

~~~
wolfgke
> I wonder if there will be a successor to Wayland and X11 that learns from
> the mistakes of both?

Ubuntu wanted to do this with Mir. The rest is history...

~~~
Valmar
A pity that the Mir devs didn't really have any experience or deep knowledge
of the Linux graphics stack...

It took the X11 devs, many of whom were also involved in Mesa and Linux
graphics development, literally years just to get all of the necessary
plumbing in place in order to replace what X11 was previously doing.

These developments help not only X11 or Wayland, but make the development of a
newer, superior protocol to X11 and Wayland much easier, because the hard
yards have been done for them.

It also makes it easier for those who might want to transition from Wayland to
a hypothetical superior protocol.

