[tor-bugs] #29429 [Core Tor/Tor]: Tor 0.3.5.7 on latest Raspbian may be generating v2 RSA keys that are unparsable by STEM/PyCrypto?

[Tor Bug Tracker & Wiki]

#29429: Tor 0.3.5.7 on latest Raspbian may be generating v2 RSA keys that are
unparsable by STEM/PyCrypto?
------------------------------+------------------------------------------
     Reporter:  alecmuffett   |      Owner:  (none)
         Type:  defect        |     Status:  new
     Priority:  Medium        |  Milestone:  Tor: unspecified
    Component:  Core Tor/Tor  |    Version:  Tor: 0.3.5.7
     Severity:  Normal        |   Keywords:  rsa key format not supported
Actual Points:                |  Parent ID:
       Points:                |   Reviewer:
      Sponsor:                |
------------------------------+------------------------------------------
 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:

 {{{
 #!/usr/bin/env python
 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.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29429>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online