Shallot
Shallot copied to clipboard
katmagic
False positives
Occasionally (actually somewhat often), shallot gets a false positive from miscalculation of the hash of the key. This is a problem, especially when automating the shallot generation of vanity keys from a script (e.g. a web hosting control panel script for Tor hidden hosting).
Here is an example:
The .onion Tor calculates is jzp2v6r772wj45db.onion. The .onion Shallot calculates is awfulpoq7czjv3ni.onion. Since Tor is the one that ultimately determines which .onion is the one that the service is ultimately reachable at, shallot is doing something wrong.
-----------------------------------------------------------------
Found matching domain after 9874468 tries: awfulpoq7czjv3ni.onion
-----------------------------------------------------------------
-----BEGIN RSA PRIVATE KEY-----
MIICXgIBAAKBgQDSsB1QmCs9zoNUa5A1/Cykgn85LtTnn5EU+iTRFly20JX3wV74
jyF2cYMQ8ibo5VWVMvsAMY2izH+DaU1crQd3L3noxFbLxspjssxB7G/jtVbnhVmK
X7gBxp7PIAaQu+AmfVyarjW+aENYz2w4p7CG5bAXnmiwHp8u4fF2r44ytwIEAJsP
xwKBgBDVJ3udaEXkxyAIPycXE1SXDe/jOQ0IH519pQ1mg+cFf/k9F5EdnQ+bEld6
1kuobLW4gUSs5Inkd3waPa6gEj8x9Rx7erJhJECLxqRPidX/vvQ4GQC/DcbXzZpe
Noxz5I0tD+6iNq4O1XHxdUk5Gcd6INS419rfGHz5BNWBtahnAkEA6IFbym3zy4vP
h8F2gOqhWwftcPMqv2Rsi8Pv+rQfAxud8n6kjNH9Kla3GkkP2BNNNcKA8LmxBIMb
IrZVSQRFbwJBAOf6XcRRWVTnsBUBgZ+SI9GXbsL1yYJOYPAg1+VvfFQDD7OpXlNF
/RnFOqlpQa2jYxImLjikFRIjgQZIaVwEkzkCQQCeFqQXGdnUfJv7Z1g/t57kF+XW
BQ9D65AYBc5eE+CP1bQENQVeeZvu8tB0Adzx1bCbiT+T8SlWFw4+dJkIuF5LAkBH
/QGmucgZ/Pv+HIO+BAott0AuegnJiKuwoq7CMpfThB+FM1mTM4v6NmjnUd5yMgg5
yqCmzNeFWsUF9rNXZ5pXAkEAvHxWVfNXSxF6GOJxwOgKk28VJrb4GjEy+Tk4jIId
WRLata6MzzJST3L3rL7FObD3ypN2cL/nekXkOCG7/6QUtQ==
-----END RSA PRIVATE KEY-----
When I use the -o flag, the onion url generated by tor from the private key never seems to correspond to the one shallot generates. When I don't use the -o flag, it seems to work fine.
Maybe this will help you locate the problem.
Seems to be multiple bugs. The base32 encoding don't agree at all with other implementations when having patterns of some size. Could be buffer overflows that are detectable with valgrind since it works flawlessly with shorter patterns. Replacing the base32 encoder did not solve the mystery with longer strings. The keys still fail in tor.
Just wanted to pop in here and say that the small code change in #9 seems to have fixed this for me.
What a difference +1 makes! Thanks mtigas for the pointer to the fix.
- Dave
Hi, So i was using the -o flag when generating a tor address. the one that was created causes tor to crash with the following errors:
Oct 31 15:54:56.000 [warn] upload_service_descriptor(): Bug: Internal error: couldn't encode service descriptor; not uploading.
Oct 31 15:54:57.000 [warn] parse error: Wrong size on key for permanent-key: 864 bits
Oct 31 15:54:57.000 [warn] Error tokenizing descriptor.
Oct 31 15:54:57.000 [warn] rend_encode_v2_descriptors(): Bug: Could not parse my own descriptor: rendezvous-service-descriptor thmywbvfflm7nsisbq3wmej4xf5srfe3
which is a bummer because i really like the address that was generated. :(
