Merge pull request #1273 from exarkun/3993.calibrate-cost-reports

Update RSA key generation docs

Fixes: ticket:3993

docs/performance.rst

@@ -82,8 +82,9 @@ network: A
 
 memory footprint: N/K*A
 
-notes: Tahoe-LAFS generates a new RSA keypair for each mutable file that it
-publishes to a grid. This takes up to 1 or 2 seconds on a typical desktop PC.
+notes:
+Tahoe-LAFS generates a new RSA keypair for each mutable file that it publishes to a grid.
+This takes around 100 milliseconds on a relatively high-end laptop from 2021.
 
 Part of the process of encrypting, encoding, and uploading a mutable file to a
 Tahoe-LAFS grid requires that the entire file be in memory at once. For larger

docs/specifications/dirnodes.rst

@@ -267,7 +267,7 @@ How well does this design meet the goals?
    value, so there are no opportunities for staleness
 9. monotonicity: VERY: the single point of access also protects against
    retrograde motion
-     
+
 
 
 Confidentiality leaks in the storage servers
@@ -332,8 +332,9 @@ MDMF design rules allow for efficient random-access reads from the middle of
 the file, which would give the index something useful to point at.
 
 The current SDMF design generates a new RSA public/private keypair for each
-directory. This takes considerable time and CPU effort, generally one or two
-seconds per directory. We have designed (but not yet built) a DSA-based
+directory. This takes some time and CPU effort (around 100 milliseconds on a
+relatively high-end 2021 laptop) per directory.
+We have designed (but not yet built) a DSA-based
 mutable file scheme which will use shared parameters to reduce the
 directory-creation effort to a bare minimum (picking a random number instead
 of generating two random primes).
@@ -363,7 +364,7 @@ single child, looking up a single child) would require pulling or pushing a
 lot of unrelated data, increasing network overhead (and necessitating
 test-and-set semantics for the modification side, which increases the chances
 that a user operation will fail, making it more challenging to provide
-promises of atomicity to the user). 
+promises of atomicity to the user).
 
 It would also make it much more difficult to enable the delegation
 ("sharing") of specific directories. Since each aggregate "realm" provides
@@ -469,4 +470,3 @@ Preventing delegation between communication parties is just as pointless as
 asking Bob to forget previously accessed files. However, there may be value
 to configuring the UI to ask Carol to not share files with Bob, or to
 removing all files from Bob's view at the same time his access is revoked.
-

src/allmydata/client.py

@@ -175,8 +175,6 @@ class KeyGenerator(object):
         """I return a Deferred that fires with a (verifyingkey, signingkey)
         pair. The returned key will be 2048 bit"""
         keysize = 2048
-        # RSA key generation for a 2048 bit key takes between 0.8 and 3.2
-        # secs
         signer, verifier = rsa.create_signing_keypair(keysize)
         return defer.succeed( (verifier, signer) )