remove key-generator #2783

New Issue

warner · 2016-04-28T05:59:06Z

warner commented

2016-04-28 05:59:06 +00:00

Hey, would anybody object if I ripped out the key-generator?

This is a standalone process that does nothing but create RSA keypairs for people who set key_generator.furl= in their tahoe.cfg . It creates them in the background so mutable-file creation doesn't need to wait. We built this back in the AllMyData days because we were worried about how long clients would block while creating keys.

I argued against removing it in #542 (in 2008), but I've changed my mind since then. I'm no longer really comfortable with users (even AllMyData-style customers) getting their keys from anywhere other than their own computers (I shouldn't have been comfortable with it back then either, really). Also it's one more daemon that needs a --location argument (#2773) that I could avoid spending time updating.

The speed used to bother me too, but on my home workstation (a 2012 Mac, 2.6GHz i7) the 2048-bit RSA key generation takes 80-90 milliseconds per key. Not great, but not a big deal.

OTOH, on the latest Raspberry Pi (v3 model B, 1.2GHz ARMv8), it takes about 1.1 seconds (per key). That's a drag, and I'm still looking forward to super-fast !Ed25519-based mutable files, but I don't think there's enough demand for an external key-generator to let the RPi speed influence our decision.

Hey, would anybody object if I ripped out the key-generator? This is a standalone process that does nothing but create RSA keypairs for people who set `key_generator.furl=` in their tahoe.cfg . It creates them in the background so mutable-file creation doesn't need to wait. We built this back in the AllMyData days because we were worried about how long clients would block while creating keys. I argued against removing it in #542 (in 2008), but I've changed my mind since then. I'm no longer really comfortable with users (even AllMyData-style customers) getting their keys from anywhere other than their own computers (I shouldn't have been comfortable with it back then either, really). Also it's one more daemon that needs a `--location` argument (#2773) that I could avoid spending time updating. The speed used to bother me too, but on my home workstation (a 2012 Mac, 2.6GHz i7) the 2048-bit RSA key generation takes 80-90 milliseconds per key. Not great, but not a big deal. OTOH, on the latest Raspberry Pi (v3 model B, 1.2GHz ARMv8), it takes about 1.1 seconds (per key). That's a drag, and I'm still looking forward to super-fast !Ed25519-based mutable files, but I don't think there's enough demand for an external key-generator to let the RPi speed influence our decision.

warner added the

labels 2016-04-28 05:59:06 +00:00

warner added this to the undecided milestone 2016-04-28 05:59:06 +00:00

warner commented

2016-04-28 06:05:56 +00:00

Incidentally, one non-security-impacting use of the key-generator would be to run it on the same machine as the client that uses it. Since python is basically single-threaded (and tahoe certainly doesn't attempt to take advantage of multiple cores), this would be a win if you're making a whole lot of mutable files, because the keys could be created on one core in the background, so the main tahoe process would be less likely to ever wait for one.

warner commented

2016-04-28 07:03:20 +00:00

BTW, in writing the patch for this, I noticed a comment from April 2008 (when the key-generator was first added) that said "RSA key generation for a 2048 bit key takes between 0.8 and 3.2 secs". Fortunately this is way faster these days.

warner commented

2016-04-28 07:11:10 +00:00

PR in https://github.com/tahoe-lafs/tahoe-lafs/pull/271

PR in <https://github.com/tahoe-lafs/tahoe-lafs/pull/271>

warner commented

2016-05-04 23:54:20 +00:00

It's been a week and nobody's complained, so the key-generator is history. RIP.

Brian Warner <warner@lothar.com> commented

2016-05-04 23:54:33 +00:00

In d1d9884/trunk:

remove "key-generator" node type and client support

closes ticket:2783

In [d1d9884/trunk](/tahoe-lafs/trac-2024-07-25/commit/d1d988410b4ebf66f8385aa940d6e5ba66ab9d89): ``` remove "key-generator" node type and client support closes ticket:2783 ```

tahoe-lafs added the

fixed

label 2016-05-04 23:54:33 +00:00

Brian Warner <warner@lothar.com> closed this issue

2016-05-04 23:54:33 +00:00

warner modified the milestone from undecided to 1.12.0

2016-05-04 23:55:37 +00:00

daira commented

2016-05-09 13:47:35 +00:00

+1. I think hardly anyone used this. We should switch to !Ed25519 keypairs if we want mutable file creation to be faster.

Sign in to join this conversation.