Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    • Menu
    Projects Groups Snippets
  • Sign up now
  • Login
  • Sign in / Register
  • H hagrid
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 28
    • Issues 28
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 3
    • Merge requests 3
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • hagrid-keyserver
  • hagrid
  • Issues
  • #131
Closed
Open
Created Aug 05, 2019 by Vincent Breitmoser@valodimOwner

Privacy and bandwidth preserving key update mechanism

Hey there,

I'd like to discuss and think through a feature that I think is very important for Hagrid: A privacy-preserving and performant key update mechanism.

First, some background:

It is desirable for openpgp implementations to regularly refresh all known keys, to notice when a key is revoked, gets new subkeys, etc. However, this use case is not considered at all in the traditional HKP API. So what implementations do to refresh a key is that they download the full key by fingerprint, and merge it into their local copy. This is then done for all keys following some schedule, for example OpenKeychain refreshes all keys over a time span of three days.

So, if keys should be updated every time span X, then within each X and for each key Y:

  • the client does one HTTP roundtrip
  • the client reveals to the keyservers that it is interested in Y
  • the client downloads and processes a full copy of Y

If we look past what we're primed to consider state of the art in OpenPGP, this mechanism is hilariously bad, in terms of privacy, performance, and traffic it causes. On keys.o.o we get about 10 requests per second on average, almost all of which are update schedules of this kind (from Enigmail and OpenKeychain). I would wager that 99% or more of those deliver no actual updates.

Assignee
Assign to
Time tracking