innix / shrek Goto Github PK

Add a Dockerfile to allow users to build and run Shrek inside a container. Useful for people who don't have Go SDK installed on their computer, or would prefer to run apps in containerized environments, or a bunch of other reasons; no need to list them all.

Also create a public remote repository on Docker Hub for users who don't want to build an image manually. This is more convenient, plus it means users can run Shrek in Docker with a single console command (using docker run).

The README should be updated with instructions on how to run Shrek with Docker.

Here's a good starting point: https://hub.docker.com/_/golang

d must be the last character in an v3 address. The CLI should warn and reject filters for :end that doesn’t end with d.

Shrek is the fastest .onion vanity address generator written in Go (at time of writing), but it's still very slow compared to native C programs like mkp224o.

As fast as my SSE2/AVX2 scalar-basepoint multiply implementation is, it is not going to compare to mkp244o because it cheats and only does one scalar-basepoint multiply per worker in the common case.

The gist of it is that instead of regenerating the entire key (expensive) each iteration of the search loop, you instead do something like:

eightTimesBasePoint = Point.Mul(Basepoint, 8) # Precompute this, though this is only called once/worker, so you could not bother.

priv, pub = GenerateKey()
scalar = ParseScalar(priv[:32])
point = ParsePoint(pub)
for {
  if Match(Encode(point) {
    // blah blah blah
  }

  scalar = scalar.Add(scalar, 1)
  point = point.Add(point, eightTimesBasePoint)
}

This does have the downside of not supporting RFC-style seed based private key representations, but IIRC tor supports/uses the expanded scalar | nonce form so keys generated by this algorithm work.

The relevant datastructures and math routines are in the curve and curve/scalar package of your ed25519 import.

nb: mkp244o does the scalar addition somewhat differently because of how I originally implemented it in the code they derived their implementation from, but the addition routine in the scalar package is sufficient (and arguably better because it is computationally impractical for wrapping to happen, so you can omit the check).