Home

Awesome

Scallion

Scallion lets you create .onion addresses for Tor's hidden services using OpenCL. It is based in part on shallot and inspired by vanitygen. The OpenCL SHA-1 implementation was adapted from NearSHA.

Scallion runs on Mono (tested in Arch Linux) and .NET 3.5 (tested on Windows 7 and Server 2008). It includes components from OpenTK and OpenSSL-net.

Scallion is currently in beta stage and under active development. Nevertheless, we feel that it is ready for use. Improvements are expected primarily in performance, user interface, and ease of installation, not in the overall algorithm used to generate keys.

Scallion is available under the MIT licence. If you use code from this project in your own projects, we'd appreciate hearing about it at scallion@aftbit.com. If you have any issues, please open a ticket here. You might also try the #scallion channel on freenode.

Note: I am now generating addresses using the secure remote generation feature for a small fee.

Please send any donations to 1onion1PNeM2x9LhdqWn6uVFyU2iSpy7M.

FAQ

Here are some frequently asked (or anticipated :) questions and their answers:

Dependancies

Binary Download

Just want the latest binary version? Grab it here.

Build Linux

xbuild scallion.sln

Build Windows

  1. Open 'scallion.sln' in VS Express for Desktop 2012
  2. Build the solution, I did everything in debug mode.

Usage

List devices

$ mono scallion/bin/Debug/scallion.exe -l

Generate a hash

$ mono scallion/bin/Debug/scallion.exe -d 0 prefix
Cooking up some delicions scallions...
LoopIteration:15  HashCount:251.66MH  Speed:89.2MH/s  Runtime:00:00:02  Predicted:00:00:12
Ding!! Delicions scallions for you!!

Exponent: 37074435
Address/Hash: prefix2bp7lfuuvp

-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQDVNxlMDVXQ6EjRLubgMUkhVeVYigEPZ4BLUhzNRp4MEMgVQHLP
GRlMc2yK29Q8fuvC1o2zJS8IF6RbXyB9Sdyuzh43st2CZeTMEWbkz6NNAJz+8UHh
1I35CWx5p4wlsw2eZx+wM7s6Ll4762pV21qolxqHoIefOsIso0AHixYPrQIEAjW2
AwKBgAEqghqEMZ2cedXc+AIKmZebbzJyWvfp9W9HRHXn6c7U0mYFNHXnAjR8KR6r
2w2IGS4LxKi360XRr70gIUw9mr9tiOlMjppkqwu7HSB0ldzCitNkVLRiV+TZQFXc
g6xxZZxX2giZoBThCq8g85/V+AyLRZK9ZdC+GkBP0YPgy8/rAkEA/j8vGpo/OkZq
3ucytAZYb+1HomUiSbh+oxMwxT84xQeSqIg/BsvWixPhuOY+7HNzdZVN458H8UXC
zSWNmmmnYQJBANave5NDwnw5w/dARWMJsAYRc7GA/wx86o/+qmw/8Q6GBkFdUqcM
2Vw0HzDIq7q1UwYBznlRCI1Wgyd5+OwDZ80CQQDaewQ811o3/8StlKLvpify+fkQ
81j0GdoUJgYCz3nDEp6sCPvg3aSI7b195odY4L3d0pQ4SnPj0zGJMFdqcwFLAkBj
A/NC23ZfVx8u1JzRojkwuE4ZAWmALIubP+iwS6I5Yj4/wz2R1veYBQX1TKNT8sOy
XA8cQ53ybVp+z39eWCPHAkAz1Sv1IOuGWS/KrC0BUQ7vtwf3z5yMUX3kMS1JF9Bf
TbEyV92GNkwxcVzMRCSeaqZXQVUIaWdbPnjYq4T6Heal
-----END RSA PRIVATE KEY-----


init: 423ms / 1 (423ms, 2.36/s)
generate key: 840ms / 45 (18.67ms, 53.57/s)
cpu precompute: 9ms / 45 (0.2ms, 5000/s)
total without init: 2828ms / 1 (2828ms, 0.35/s)
set buffers: 0ms / 15 (0ms, 0/s)
write buffers: 2ms / 15 (0.13ms, 7500/s)
run kernel: 0ms / 15 (0ms, 0/s)
read results: 2812ms / 15 (187.47ms, 5.33/s)
check results: 5ms / 15 (0.33ms, 3000/s)

88.99 million hashes per second

Multipattern Hashing

Scallion supports finding one or more of multiple patterns through a primitive regex syntax. Only character classes (ex. [abcd]) are supported. The "." character represents any character. Onion addresses are always 16 characters long, so a suffix can be found by prepending the correct number of dots. You can also find a suffix by putting a $ at the end of the match. Finally, the pipe syntax (ex. "prefix|pattern") can be used. Adding more patterns (within reason) will NOT produce a significant decrease in speed because the internal implementation has a constant time lookup. Using multiple patterns may produce an ~8% decline in total hash speed, but many regexps will produce a single pattern on the GPU.

Some use cases with examples:

<a name="SRKG"></a> Secure Remote Key Generation

Many people have asked about the ability to perform split-key generation like VanityGen supports. Unfortunately, as far as I understand it, RSA does not lend itself to split-key generation. However, I have implemented secure remote key generation. As it so happens, Scallion mines for onion addresses by changing the public key exponent on the fly. With the current configuration, a single public key is good for around 1 GH worth of work. So I've added the ability for Scallion to export a list of public key moduli. This list may then be sent to an untrusted 3rd party, who can use it to mine for onion addresses. They will then return a work file to you which contains the modulus and exponent that generates a matching onion address. You can then plug this into scallion and have it look up and output the private key for you.

Usage Example

Performance

My ivybridge i7 can generate 51 keys per second using a single core. I'm not sure if the OpenSSL lib is thread-safe, but this could probably be improved if needed.

Each (1024-bit) key is output as a decimal encoded modulus (should have used hex, but too late now), taking 310 bytes per key. The private key is also output with the modulus, taking 1215 bytes per key.

Each key can provide 1 gigahash worth of exponents to mine. This could be improved by roughly a factor of two at the expense of code complexity and/or a large drop in mining hashrate. However, Scallion generates 5x as many keys as are needed in the average case to help ensure that the remote host won't run out of work. Remember, this is a probabilistic process.

In order to mine for an 8 character prefix, you'd need around 2580 keys, which would take around 1 minute to generate on a relatively modern CPU, and which would produce a public key file about 1 MB. The private key file would be about 3 MB. Finally, on a 520MH/s GPU (like my 5770) this prefix would take on average around 17 minutes to mine.

In order to mine for a 9 character prefix, you'd need around 82565 keys, which would take around 30 minutes to generate on a relatively modern CPU, and which would produce a public key file about 24 MB. The private key file would be about 95 MB. Finally, on a 520 MH/s GPU (like my 5770) this prefix would take on average around 10 hours to mine.

In order to mine for a 10 character prefix, you'd need around 2642160 keys, which would take around 15 hours to generate on a relatively modern CPU, and which would produce a public key file about 781 MB. The private key file would be about 3 GB. Finally, on a 520 MH/s GPU (like my 5770) this prefix would take on average around 12 days and 12 hours to mine.

In order to mine for an 11 character prefix, you'd need around 84549200 keys, which would take around 19 days to generate on a relatively modern CPU, and which would produce a public key file about 24 GB. The private key file would be about 96 GB. Finally, on a 520 MH/s GPU (like my 5770) this prefix would take on average around 400 days to mine.

There are some major potential space savings in the size of these files (e.g. using hex or a binary encoding for the keys).

The 3rd party mode mining performance is very similar to the normal mode. The keys are read in at startup and the full list is kept in RAM, and there is a small (< 5 MH/s for me) drop in hashrate because of the need to save used keys to the continuation file, but beyond that, it's identical.

Service

Contact me at scallion@aftbit.com if you're interested in having me generate a key for you using this feature. I've drawn up a pricing table and some performance specifications at saas.md.

Speed

On my nVidia Quadro K2000M, I see around 90 MH/s. With those speeds, I can generate a six character prefix in about six seconds on average. An eight character prefix would take about 1h 45m. To calculate the number of seconds required for a given prefix (on average), use this formula:

seconds = 2^(5*length-1) / hashspeed

My AMD Radeon HD5770 gets 520 MH/s.

My friend's AMD Radeon HD6850 gets 600 MH/s. That's a 300x speedup over shallot. With that speed, he can find an eight character prefix in just 15 minutes on average.

On a NVIDIA GTS 250, I get about 126-129 MH/s with a single-pattern match and about 101-119 MH/s with multi-pattern match. With shallot I got about 500kH/s.

kH/s = thousand hashes per second.

MH/s = million hashes per second.

Workgroups

This will use your devices reported preferred work group size by default. This is the most compatiable way for it to run, but you should experiment with the numbers to try to get the highest as possible for increased performance.

Security

The keys generated by Scallion are quite similar to those generated by shallot. They have unusually large public exponents, but they are put through the full set of sanity checks recommended by PKCS #1 v2.1 via openssl's RSA_check_key function. In general, however, tor's (and Scallion's) default 1024-bit key is starting to look a little small. Scallion supports several RSA key sizes, with optimized kernels for 1024b, 2048b, and 4096b. Other key sizes may work, but have not been tested.

Donations

Feel free to direct donations to the Bitcoin address: 1FxQcu6vhpwsqcTjPsjK43CZ9vjnuk4Hmo