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.