Opened 6 years ago

Last modified 7 months ago

#6369 assigned task

Gather empirical data on AES/RSA operations performed by typical relays or bridges

Reported by: karsten Owned by: metrics-team
Priority: Medium Milestone:
Component: Metrics/Analysis Version:
Severity: Normal Keywords: nickm-cares
Cc: nickm, arma, teor Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

At the Florence hackfest I was asked for the typical number of AES/RSA operations performed by a relay or bridge, say, per day. This information is relevant, e.g., for designing the hardware capabilities of a Torouter device.

Here's my plan to find out:

  • We can easily derive the number of AES operations by looking at the total traffic pushed by relays and bridges. Extra-info descriptors contain bandwidth histories that we could use here. If we assume 1 AES operation per 16 written or read bytes, we should be quite close to reality.
  • Nick suggested to send a USR1 signal to a tor process to write lines like this to their log (this line comes from a client):

Jul 10 18:31:22.904 [info] PK operations: 0 directory objects signed, 0 directory objects verified, 0 routerdescs signed, 2968 routerdescs verified, 216 onionskins encrypted, 0 onionskins decrypted, 30 client-side TLS handshakes, 0 server-side TLS handshakes, 0 rendezvous client operations, 0 rendezvous middle operations, 0 rendezvous server operations.

We could ask a few friendly relay and bridge operators on tor-talk to tell us the number of encrypted and decrypted onionskins together with the fingerprint. We can then look at the uptime of that relay or bridge in the descriptor archives and compute the average number of operations per day.

Is there an easier way to find out how many AES/RSA operations a relay or bridge does per day?

Child Tickets

Change History (10)

comment:1 Changed 6 years ago by karsten

weasel just said on #tor-dev that 1 AES operation may not be correct for 16 written or read bytes. That number doesn't include TLS on incoming and outgoing side. So, a middle node would do AES-for-TLS, AES, AES-for-TLS, that is, 3 AES operations. An exit wouldn't do the final AES-for-TLS, so just 2 AES operations. But 3 may be a good upper bound here.

Does that make sense? Or is 3 AES operations per 16 bytes of relayed data still totally off?

comment:2 Changed 6 years ago by karsten

I asked a few relay operators on tor-relays to send me part of the log line above. Here are the results (average per second of operation):

FingerprintKB writtenonion skins decryptedAES operationsAES/RSA ratio
8DE56208.5614.252384088167288
05304.990.04191648250
C0ED32.43<0.141245288943
110A4.000.02153774969
E47B22.200.27852531988
7C8525.790.23990142929

Remarks:

  • The KB written part comes from bandwidth histories that all relays report to the directory authorities. These histories are in 15-minute intervals which we can easily break down to a per-second number.
  • onion skins decrypted comes from the log line reported by relay operators. The per-second number comes from the log timestamp and the last restart time as reported by relays to the directory authorities.
  • AES operations is simply 384 times KB written. The assumption is that each chunk of 16 written bytes requires 3 AES operations, times 2, because for every written byte, the relay also reads one byte on average.
  • The AES/RSA ratio is simply AES operations divided by onion skins decrypted.

Does this make sense?

comment:3 Changed 6 years ago by karsten

Closing the ticket, because we have some results here. Please re-open if we need more results to the specific question. Or open a new ticket for a new question.

comment:4 Changed 6 years ago by karsten

Roger notes that the numbers above don't account for bursts, which may become more common when we implement Mike's isolate-by-destination plan. We do have data to at least approximate AES operation bursts by looking at the most busy 15 minutes in a day. But we don't have similar data for RSA operations.

If there's a strong need to get more data about bursts, please re-open this ticket. I'd rather want to avoid spending more time on this analysis, unless there's a need to do so.

comment:5 Changed 6 years ago by cypherpunks

one more datapoint from an excito b3:

Sun Jul 29 23:42:20 CEST 2012
1032283 onionskins decrypted
159277 routerdescs verified
30 onionskins encrypted
(I prefer not to provide identity (FP) information.)

comment:6 Changed 5 years ago by karsten

Owner: karsten deleted
Status: newassigned

This isn't something I'm working on, nor something I'll be working on soon. Unassigning.

comment:7 Changed 13 months ago by nickm

Keywords: nickm-cares added

comment:8 Changed 13 months ago by karsten

Owner: set to metrics-team

comment:9 Changed 10 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:10 Changed 7 months ago by irl

Cc: teor added; ioerror removed

This may also be a good candidate for implementation using PrivCount.

Note: See TracTickets for help on using tickets.