
CS Alert (1890) - rmbryan
https://en.wikipedia.org/wiki/CS_Alert_(1890)
======
gnulinux
Meta HN question (I'm sorry if this is inappropriate). Normally, in HN
"{Title} ({Year})" signals that the article is written in "Year". So when I
read the title, I thought the article will be from 1890, but then realized the
article is named "CS Alert (1890)". In this case looks like "(1890)" is added
to the title to disambiguate it from other "CS Alert"s i.e.:
[https://en.wikipedia.org/wiki/CS_Alert](https://en.wikipedia.org/wiki/CS_Alert)

I initially thought it would make more sense to name this article as "CS
Alert" since it wouldn't matter as much as Wikipedia if the title is
ambiguous. But then I disagreed with myself since other "CS Alert"s are all
named of the form "CS Alert ({Year})" so it could still be ambiguous even in
HN context. Maybe the title could editorialized to "CS Alert 1890" or "CS
Alert, 1890" or something, but I understand that HN rules are against
editorializing titles. It's an interesting problem.

~~~
rmbryan
Maybe wikipedia should be exempt from the dating rule, since, what's the
publication date on a wikipedia entry?

~~~
0xffff2
I think the problem here is that the literal string "(1890)" is part of the
original title.

------
mikeash
Interesting that they cut the lines instead of tapping them. Maybe the
technology wasn’t there yet, or they were in too much of a hurry.

~~~
gwbas1c
It would probably be obvious if there was always a ship over the cables.

~~~
rmbryan
I wonder if there are cases where it's better to cut an enemy cable, as
opposed to tapping it. I can't think of any, but this isn't my field.

~~~
henryfjordan
Tapping the cable still allows the enemy to talk.

Sometimes, if the enemy is trying to be sneaky, it's better to overhear them
and thwart their efforts.

Other times the enemy might be trying to coordinate a massive attack for which
timing is key. It wouldn't matter if you overhear because you need to disrupt
the attack before it starts. In that case it's better to not let the enemy
communicate at all.

~~~
ryacko
Still doesn’t explain why layer 1 encryption isn’t used for oceanic cables.

Edit: I mean this from a timeless perspective, and slightly from the present
day.

~~~
krastanov
In 1915!? Because mathematically sound encryption and the computational
machinery to employ it did not exist back then.

~~~
dboreham
Hmm...sound encryption did exist: [https://en.wikipedia.org/wiki/One-
time_pad#History](https://en.wikipedia.org/wiki/One-time_pad#History)

And computational machinery to implement it, at least for telegraph seems to
have quite likely existed in 1915:
[https://patents.google.com/patent/US1310719](https://patents.google.com/patent/US1310719)
(filing date 1917).

~~~
mindslight
A one time pad is not "sound encryption", as it lacks message integrity.

~~~
ryacko
Layer 1 encryption doesn’t involve message integrity.

~~~
mindslight
That's a weird assertion, but okay.

My only point was that by the modern standards we take for granted, OTP/XOR is
not really a cryptosystem but better thought of as a primitive. IMO for those
just learning crypto, it's a red herring that hides the core functionality of
modern cryptography (see: the common amateur reinvention of using a PRNG as a
OTP).

My answer to your main question is because encrypting layer 1 adds negligible
security properties to the whole system (can't tap that link, but you can tap
anywhere else), everything should already be encrypted at a higher level (for
the previous reason, as well as integrity/authorization/etc), and that the
bandwidth is too high (the entire point of packet switched networks is to do
as little as possible in each node).

Applied to the existing Internet, the only thing it would gain is hiding
addressing metadata from an attacker who directly taps a link.

A more effective general way of doing this would be something like onion
source routing, where each router only knows the next hop. But once again the
scalability problem, so the desire is better applied to an overlay network
rather than convincing backbone providers to take this on - there is barely
the impetus for IPv6.

