mirror of
https://github.com/tahoe-lafs/tahoe-lafs.git
synced 2024-12-30 09:48:56 +00:00
82579cec96
Add ".. -*- coding: utf-8-with-signature -*-" to the first line of each .rst file. This tells emacs to treat the file contents as utf-8, and also to prepend a so-called utf-8 "bom" marker at the beginning of the file. This patch also prepends those markers to each of those files.
60 lines
3.2 KiB
ReStructuredText
60 lines
3.2 KiB
ReStructuredText
.. -*- coding: utf-8-with-signature -*-
|
|
|
|
=======================================================
|
|
Things To Be Careful About As We Venture Boldly Forth
|
|
=======================================================
|
|
|
|
See also known_issues.rst_.
|
|
|
|
.. _known_issues.rst: known_issues.rst
|
|
|
|
Timing Attacks
|
|
==============
|
|
|
|
Asymmetric-key cryptography operations are particularly sensitive to
|
|
side-channel attacks. Unless the library is carefully hardened against timing
|
|
attacks, it is dangerous to allow an attacker to measure how long signature
|
|
and pubkey-derivation operations take. With enough samples, the attacker can
|
|
deduce the private signing key from these measurements. (Note that
|
|
verification operations are only sensitive if the verifying key is secret,
|
|
which is not the case for anything in Tahoe).
|
|
|
|
We currently use private-key operations in mutable-file writes, and
|
|
anticipate using them in signed-introducer announcements and accounting
|
|
setup.
|
|
|
|
Mutable-file writes can reveal timing information to the attacker because the
|
|
signature operation takes place in the middle of a read-modify-write cycle.
|
|
Modifying a directory requires downloading the old contents of the mutable
|
|
file, modifying the contents, signing the new contents, then uploading the
|
|
new contents. By observing the elapsed time between the receipt of the last
|
|
packet for the download, and the emission of the first packet of the upload,
|
|
the attacker will learn information about how long the signature took. The
|
|
attacker might ensure that they run one of the servers, and delay responding
|
|
to the download request so that their packet is the last one needed by the
|
|
client. They might also manage to be the first server to which a new upload
|
|
packet is sent. This attack gives the adversary timing information about one
|
|
signature operation per mutable-file write. Note that the UCWE
|
|
automatic-retry response (used by default in directory modification code) can
|
|
cause multiple mutable-file read-modify-write cycles per user-triggered
|
|
operation, giving the adversary a slightly higher multiplier.
|
|
|
|
The signed-introducer announcement involves a signature made as the client
|
|
node is booting, before the first connection is established to the
|
|
Introducer. This might reveal timing information if any information is
|
|
revealed about the client's exact boot time: the signature operation starts a
|
|
fixed number of cycles after node startup, and the first packet to the
|
|
Introducer is sent a fixed number of cycles after the signature is made. An
|
|
adversary who can compare the node boot time against the transmission time of
|
|
the first packet will learn information about the signature operation, one
|
|
measurement per reboot. We currently do not provide boot-time information in
|
|
Introducer messages or other client-to-server data.
|
|
|
|
In general, we are not worried about these leakages, because timing-channel
|
|
attacks typically require thousands or millions of measurements to detect the
|
|
(presumably) small timing variations exposed by our asymmetric crypto
|
|
operations, which would require thousands of mutable-file writes or thousands
|
|
of reboots to be of use to the adversary. However, future authors should take
|
|
care to not make changes that could provide additional information to
|
|
attackers.
|