Tor 0.3.5.7 may be generating v2 RSA keys that are unparsable by STEM/PyCrypto?
I am developing EOTK - https://blog.torproject.org/volunteer-spotlight-alec-helps-companies-activate-onion-services - this means a lot of work with OnionBalance and STEM, and a lot of disposable Onion addresses; so I am going to break a cardinal rule and intentionally paste some private keys into this bug report. It's okay, they are trash anyway.
This evening I have found behaviour that I have not seen before, and I would like to report it.
I have built Tor from source:
Feb 07 21:35:37.251 [notice] Tor 0.3.5.7 running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2q, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.
I am running it on Raspbian Stretch, latest-everything, compilers, etc; happy to give specific details upon request.
I have generated 12 onion addresses by means of launching Tor with a configuration file that looks like this:
DataDirectory $dir/ Log info file $dir/tor.log PidFile $dir/tor.pid RunAsDaemon 1 SocksPort 0 HiddenServiceDir $dir HiddenServicePort 1 127.0.0.1:1 HiddenServiceVersion 2
...running it as "tor -f $dir/config", killing the daemon after a few seconds, and then scraping $dir for the onion private key for deployment / reuse. Relevant source code at: https://github.com/alecmuffett/eotk/blob/master/lib.d/generate-onion-key.sh
This gives me the 12 onion addresses that I need, and normally this would work, however OnionBalance is not accepting some of the addresses; I cut the OnionBalance python code down to this simple test:
import sys import Crypto from Crypto.PublicKey import RSA for fname in sys.argv[1:]: with open (fname, 'rt') as fh: pem = fh.read() # slurp try: rsa = Crypto.PublicKey.RSA.importKey(pem, passphrase=None) except Exception as e: print fname, e else: print fname, rsa.size()
...which I then run against my 12 keys:
$ ./pemtest.py secrets.d/*.key secrets.d/3rxg2cbaolntggg6.key 1023 secrets.d/gno6yqj4uik34nbk.key 1023 secrets.d/gpozevhubaeuimoy.key RSA key format is not supported secrets.d/l4gymyc6r3zbkafu.key 1023 secrets.d/mrukxceh7grqzmbr.key 1023 secrets.d/ntz22knrkak4od7q.key RSA key format is not supported secrets.d/pjclxtjzo7g7wiwd.key 1023 secrets.d/qjgqctbh2rkm3ov2.key 1023 secrets.d/sr4xt3tiz4lietmo.key RSA key format is not supported secrets.d/udtev77zeo6x7bli.key RSA key format is not supported secrets.d/y62hgkk2ztzhkfzz.key 1023 secrets.d/zdsv5364zgb6m7l6.key RSA key format is not supported
...and the problem is fairly evident; to take this one as an example:
$ cat secrets.d/ntz22knrkak4od7q.key -----BEGIN RSA PRIVATE KEY----- MIICXQIBAAKBgQDsCx3zjT0R13eQkUuhJgb6pG5z2zF+6baeJrc3JSCstQh/8tR4 5yI3Gwo7c1sRGA4Yjy8RrOKhMg3uXd+NyekySGlxpK4evKq22g2+TX73yOpJ5yVH h655rZEUwoYq1M3HBL4nhIwSBt5js2/pGVyvMT2aZeMDo45NQ7Bb/t3/AQIDAQAB AoGAMUgk6bu8W2REJ1/ejXe2D1CTawcBr4C2SxDEQfQzfTuS2bvmVpPTVfQET+NG ySvfjYsfha415vffZrwct6rHT/yed7KBN3l4DeF4PfQNBfBNHUj08Z3WQBwuhTZQ Sh15Oc2iuZ2ZwEzH7bjP7sMz6FW3hQ10MY/Fe7zGAOd4Is0CQQD2zJp/7jr9ySnI ciu7VXO1wsxKKmrswTod+V/R0teTTZemDKNtEtX9ol61MOfoAjXhyRRmk3JgkXtA r2XdvOXvAkEA9Nfcy1bWR+E1LmFg6S4GarG95a4fvQlQNEKvJLjHw25GZ1iRKdbb orP0qiw6enA0PhOwKy373kFvzTNVQfHaDwJBAITLHIqfZbBuUAQhonQ/C26ObRuu 7S+M3LeKGcutlf8VbfaTsE+dJfU+K5V0xiNpJRLi/g4fYhihzt7EQZxo6pMCQAtQ 8sZ/I/Y8hW24WHdOhkNmJaW474SYKpnPvzKOS8VPkndyU3tAj/QsJxG6a5V/HBsG Y+0K+goish0k0zryB6cCQQDo/u8TeKKiJbH2I8PJNtja6+yRcS2IashnqMLQYHBS 4W1lcmZcXxyj7Re7jexM7W83s3XG6rpLoLNzmmUoFyZI -----END RSA PRIVATE KEY-----
I ran it through a online validator which appeared happy, so I am wondering if there is some edge-case recently arrived in Tor v2 Key Generation, which is breaking PyCrypto and hence OnionBalance and/or other STEM-dependent code?
The full set of keys (good and bad) is available on request.