lazard

How can we help with getting support for Ed25519 in crypto/x509 and crypto/tls?

Not possible yet, but I have some ideas.

Our followup Karaoke system [1] can support more users by adding more servers, but we still have more work to do to support billions of users. Regardless, I think it's worth deploying these research prototypes to get a sense of what problems matter to users.

[1] https://vuvuzela.io/static/karaoke.pdf

It doesn't yet. I'd like to integrate Karaoke's techniques into the Vuvuzela client in the coming months.

Thanks. I just added our latest paper to the list.

Sorry! We signed and uploaded new configs, so it should be working now.

Sorry about that. I need some way to prevent someone from quickly registering many email addresses. Do you have any other ideas?

Our latest paper, Karaoke, achieves 6.8 seconds with 2 million active users: https://vuvuzela.io/static/karaoke.pdf

Nice! Looks similar to Seal [1] (also written in Go). I just added a link to Pick under related work.

[1] https://github.com/davidlazar/seal

I used pwclip [1] for several years but I no longer believe that hash-based password managers are the best plan. Now I'm using Seal [2], which is like pass but doesn't depend on gpg.

[1] https://github.com/davidlazar/pwclip

[2] https://github.com/davidlazar/seal

We measured 10% improvement on ppc64.

The compiler got a bit slower:

https://github.com/golang/go/issues/19386

Those numbers are just for my CLs that fix stack traces but with mid-stack inlining still off. Turning it on makes builds noticeably slower:

    $ time ./make.bash
    real: 45.32s  user: 118.67s  cpu: 5.85s

    $ time GO_GCFLAGS='-l=4' ./make.bash
    real: 64.51s  user: 167.04s  cpu: 7.12s

We'll need to tweak the inlining heuristic to find a good balance between performance, build times, and binary size.

The plan is to add inlining information to the DWARF tables so that debuggers and other tools can take advantage of it.

Only temporarily. I'm interning on the Go team, but still working on Vuvuzela and Alpenhorn in my spare time.

Author here.

I've been working on a follow-up system called Alpenhorn that addresses the bootstrapping problem in Vuvuzela: https://vuvuzela.io/alpenhorn-extended.pdf

I will release Alpenhorn and a new version of Vuvuzela in January.

I built flycrypt as a highly simplified PGP based on NaCl. I've used it to send credit card numbers and passwords over email.

https://github.com/davidlazar/flycrypt

We're using noise to hide metadata in the Vuvuzela messaging system [1]. Using noise to hide metadata is efficient and gives good privacy (better than Tor-based approaches). We've formalized the privacy guarantee using differential privacy and are now working to make the system more user-friendly and easier to deploy.

[1] https://github.com/davidlazar/vuvuzela

The slides toward the end of my talk [1] try to give some intuition for Vuvuzela's security in terms of "jury certainty".

[1] https://davidlazar.org/slides/vuvuzela-sosp2015.pdf

Author here:

The latency can be reduced by future work. For example, Section 9 in the paper mentions an idea for reducing the amount of noise (and thus reducing latency) by treating honest users as noise.

Vuvuzela can also be configured with a smaller "privacy budget" to reduce latency.

I created my own: https://github.com/davidlazar/jotmuch