[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[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?
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs