[Cryptography] Whether Henry Spencer's key-leak would be detected

[John Gilmore]

> If one in 65K packets were undecodeable, someone would notice very
> quickly.  Some users don't monitor the quality of their network
> connections, but many do. There's no way this could masquerade as bit
> errors on the underlying connection:  The undetected (by lower-level
> hardware/code) error rate is in the 1 in billions range.

I tend to disagree.

Back in 1983 on the Sun engineering Ethernet, we discovered that a
significant fraction of the packets were failing the CRC checks in
their Ethernet chips -- more than twice the "1 in billions" fraction
suggested in the Ethernet specs.

We never ran down why.  We were hard-pressed to just ship products to
willing customers -- we had a 6-month backlog of orders -- and the
higher level protocols were detecting the errors, retrying, and
recovering, so the practical effect was a minor retry every once in
a while.  The Engineering net was the most diverse and complicated
Ethernet we ran internally to Sun; we didn't see this problem on
simpler test networks or other networks there.

Such a problem could have been anywhere in the protocol stack -- from
the physical fat-yellow-ethernet cables, to the transceiver circuitry,
the transceiver cables, the sending Ethernet chips, their DMA engines
and memory-timing circuitry that supplied them, the RAM chips that
held the packets, the receiving Ethernet chips and their RAM and DMA,
the software that built the packets, etc.  Our engineering
organization had most of the right people to run down the problem (we
had few analog engineers, but otherwise we had BUILT much of this
hardware and software ourselves).  But we had neither the time nor the
motivation to do so.

At customer sites, even if they had the time to spend on it, and the
motivation to do so, they would seldom have had the expertise to run
down the actual problem.  Which would be very good for the attacker,
if the actual problem was that a subverted component was leaking key
materials into the packets.

In today's Ethernets, a defender would also have to look at the CRC
error rates in each switch, not merely on the endpoint systems, since
many switches check CRCs and filter out erroneous packets.  So, if an
attacker can subvert the firmware in a switch, a great way to leak
information from a host is to deliberately send it in packets with a
bad CRC.  That packet will only travel on the physical cable between
the host and the switch, making it VERY hard for a defender to detect
it.  (The switch would have to leak the data to the outside world in
some other way -- perhaps in a different deliberately-mangled packet
being sent to a different and more remote destination.)

What's the CRC error rate on *your* local Ethernet?  How does it compare
to the IP checksum failure rate?  The TCP checksum failure rate?  When
is the last time you looked?

	John

PS: In many Ethernet packets there are many "don't-care" bits.  For
example, the minimum Ethernet packet size is 64 bytes (46 bytes of
payload).  The minimum size of an IP packet is smaller -- 20
bytes of IP and 20 bytes of TCP -- so every time a TCP acknowledgement
packet is sent without data, there are 6 bytes of "padding" at the
end of the TCP/IP packet carried inside the 64-byte Ethernet packet.
According to RFC 894, these padding bytes are supposed to be sent as
zeroes, but there is no requirement to check them at the receiving
end.  Do *you* know how many padding bytes sent or received on your
network are nonzero?

Sending minimum sized packets happens frequently.  Most TCP
connections have a phase in which a lot of data flows in one
direction, and none in the other direction.  For example, when
accessing a web page with HTTP, the client sends a request (while the
server sends nothing but ACKs), then the client sends nothing but ACKs
while the server sends the contents of the web page.  Some of the
packets used to open or close a TCP connection are also often of
minimum size.  DNS queries are also often shorter than the minimum
Ethernet packet size too.  So an attacker could leak many bytes per
second without even using packets with bad CRC's.