-
Notifications
You must be signed in to change notification settings - Fork 2
Server Side Encryption
(inspired by zerodb.io)
- rows have clear and crypted fields.
- 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.
- 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?
- 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?