Skip to content

Server Side Encryption

Don Park edited this page Mar 1, 2016 · 17 revisions

(inspired by zerodb.io)

layered on rethink

  • rows have clear and crypted fields.

Commons queries

  • Level 1
    • User page view, last 100 points: filter on user id and date. order by date.
    • Fence list: filter by user
  • Level 2
    • Fence trigger: last location, inside any fence.

Basic encryption (level 1)

  • two-way cipher for lat/lng fields only. client owns secret.
  • client secret is stored server-side using a public key
  • each friend has a copy of the secret, encrypted with that user's public key
  • location records returned as normal. client side decrypts secret with private key, uses secret to decrypt lat/lng
  • service becomes dumb storage. Maybe this opens the door to federated storage services?

Level 2 Support ideas

Partial Encryption / obfusticated coordinate system

  • encrypted properties given two encrypted points
    • determine direction between points

Client secret: an offset to lat/lng. Locations are 'distorted' before sending to server. Points are on their own map coordinate system. fail: Distances between points are the same. Mapping lots of points will draw a map of the city in the new system.

Instead of a fixed offset, a client algorithm that distorts distances by a variable amount. a wavey line, deterministically established by a client secret. a polynomial expression with the client holding the coefficients. This works for storage. Makes client side fence detection impossible. update: thats no better than plain old encryption.

For fence alerts, detecting a point inside a polygon. An algo that isn't dependent on distance, but NSEW of a point. Is that enough to determine inside or not? Is it so much as to make distortion useless?

randomize the value while keeping the relation

Clone this wiki locally