Relationship integrity #1980

josephschorr · 2024-07-08T21:23:53Z

NOTE: the new columns are not yet implemented outside of memdb and CRDB, so those tests will fail

Addresses: #1953

jzelinskie · 2024-07-08T21:27:06Z

internal/datastore/crdb/crdb.go

+	colRelation          = "relation"
+	colUsersetNamespace  = "userset_namespace"
+	colUsersetObjectID   = "userset_object_id"
+	colUsersetRelation   = "userset_relation"


maybe put a new line here to keep all the caveat stuff together

jzelinskie · 2024-07-08T21:27:55Z

internal/datastore/crdb/migrations/zz_migration.0007_add_integrity_columns.go

+)
+
+func init() {
+	err := CRDBMigrations.Register("add-integrity-columns", "add-relationship-counters-table", addIntegrityColumns, noAtomicMigration)


is there a must register? i swear it's been written at some point

Nope, we never added it. We could, but this seems fine

jzelinskie · 2024-07-08T21:29:32Z

internal/datastore/crdb/reader.go

@@ -36,6 +36,9 @@ var (
 		colUsersetRelation,
 		colCaveatContextName,
 		colCaveatContext,
+		colIntegrityKeyID,
+		colIntegrityHash,
+		colTimestamp,


do we need the timestamp if we have the key id?

Yes, to ensure that if a key is expired, we can still accept relationships signed from before the expiration time

jzelinskie · 2024-07-08T21:32:14Z

internal/datastore/proxy/relationshipintegrity.go

+	var sb strings.Builder
+	sb.WriteString(tpl.ResourceAndRelation.Namespace)
+	sb.WriteString(":")
+	sb.WriteString(tpl.ResourceAndRelation.ObjectId)
+	sb.WriteString("#")
+	sb.WriteString(tpl.ResourceAndRelation.Relation)
+	sb.WriteString("@")
+	sb.WriteString(tpl.Subject.Namespace)
+	sb.WriteString(":")
+	sb.WriteString(tpl.Subject.ObjectId)
+	sb.WriteString("#")
+	sb.WriteString(tpl.Subject.Relation)
+
+	if tpl.Caveat != nil && tpl.Caveat.CaveatName != "" {
+		sb.WriteString(" with ")
+		sb.WriteString(tpl.Caveat.CaveatName)
+		sb.WriteString(":")
+		sb.WriteString(tpl.Caveat.Context.String())
+	}


is this something we can put in the tuple package? maybe something similar already exists

Yes, we could put it into there

jzelinskie · 2024-07-08T21:33:37Z

internal/datastore/proxy/relationshipintegrity.go

+func (r *relationshipIntegrityProxy) CheckRevision(ctx context.Context, revision datastore.Revision) error {
+	return r.ds.CheckRevision(ctx, revision)
+}
+
+func (r *relationshipIntegrityProxy) Close() error {
+	return r.ds.Close()
+}
+
+func (r *relationshipIntegrityProxy) Features(ctx context.Context) (*datastore.Features, error) {
+	return r.ds.Features(ctx)
+}
+
+func (r *relationshipIntegrityProxy) HeadRevision(ctx context.Context) (datastore.Revision, error) {
+	return r.ds.HeadRevision(ctx)
+}
+
+func (r *relationshipIntegrityProxy) OptimizedRevision(ctx context.Context) (datastore.Revision, error) {
+	return r.ds.OptimizedRevision(ctx)
+}
+
+func (r *relationshipIntegrityProxy) ReadyState(ctx context.Context) (datastore.ReadyState, error) {
+	return r.ds.ReadyState(ctx)
+}
+
+func (r *relationshipIntegrityProxy) RevisionFromString(serialized string) (datastore.Revision, error) {
+	return r.ds.RevisionFromString(serialized)
+}
+
+func (r *relationshipIntegrityProxy) Statistics(ctx context.Context) (datastore.Stats, error) {
+	return r.ds.Statistics(ctx)
+}


i like to make functions like these 1 single line so they all stack together without newlines between. it makes it more clear that they're just boilerplate

Tried but go is reformatting it back to this

Likely because the receiver is named relationshipIntegrityProxy and thus its making the lines too long. Shall I rename the struct?

ecordell · 2024-07-08T21:33:53Z

internal/datastore/proxy/relationshipintegrity.go

+	currentKeyHMAC := hmacConfig{
+		keyID:     currentKey.ID,
+		expiredAt: currentKey.ExpiredAt,
+		hmacPool: &sync.Pool{


I'm sure it depends, but for tiger I found that a buffered channel performed better than sync.Pool (select on retrieving from the pool to return a new instance if the pool is empty, similar to sync.Pool)

ecordell · 2024-07-08T21:34:36Z

internal/datastore/proxy/relationshipintegrity.go

+			keyID:     key.ID,
+			expiredAt: key.ExpiredAt,
+			hmacPool: &sync.Pool{
+				New: func() any { return hmac.New(alg, key.Bytes) },


it's probably worth benchmarking sha3 here, since you can use it as a MAC directly instead of through an HMAC

I also learned recently about https://github.com/google/highwayhash (and its Go native impl, https://github.com/minio/highwayhash), theoretically 1 order of magnitude faster than SHA256 thanks to SIMD. The go implementation says:

HighwayHash is not a general-purpose cryptographic hash function (such as Blake2b, SHA-3 or SHA-2) and should not be used if strong collision resistance is required.

But the reference C++ implementation from Google says:

Given a strong hash function and secret seed, it appears infeasible for attackers to generate hash collisions because s and/or R are unknown. However, they can still observe the timings of data structure operations for various m. With typical table sizes of 2^10 to 2^17 entries, attackers can detect some 'bin collisions' (inputs mapping to the same bin). Although this will be costly for the attacker, they can then send many instances of such inputs, so we need to limit the resulting work for our data structure.

Did some prelim tests and highwayhash is faster by about ~50% while SHA3 seemed to be slower.

However, I'm concerned about the lack of strong collision resistance. We'll need to investigate the implications of that.

Updated branch with the highwayhash impl for testing

The scenario this attempts to protect from is unauthorized modification of the state of the database. This requires sophisticated attacks and computing running for days to find a collision that could reveal the seed. If someone has access to the database and the machinery to run such an attack, the hash is not going to get in the way honestly, they probably have enough incentives to find other ways. I don't think remote attacks, with all the level of indirections, can give a clear signal to an attacker.

This is a decision the customer could themselves make and we could make it configurable via a flag. If the customer considers only collision-resistant hashes acceptable and are willing to accept the tradeoff in computational cost, then they can choose to do so. Highwayhash is by no means a "weak" hash, but one that makes the attack cost be sufficiently high to be unfeasible to most attackers.

By contrast, 'strong' hashes such as SipHash or HighwayHash require infeasible attacker effort to find a hash collision (an expected 2^32 guesses of m per the birthday paradox) or recover the seed (2^63 requests). These security claims assume the seed is secret. It is reasonable to suppose s is initially unknown to attackers, e.g. generated on startup or even per-connection.

Consider the authors describe how complicated an attack is:

A timing attack by Wool/Bar-Yosef recovers 13-bit seeds by testing all 8K possibilities using millions of requests, which takes several days (even assuming unrealistic 150 us round-trip times). It appears infeasible to recover 64-bit seeds in this way.

…ests

… they are written, and matches hashes when they are read

ecordell · 2024-07-11T21:59:48Z

internal/datastore/proxy/relationshipintegrity.go

+type relationshipIntegrityProxy struct {
+	ds         datastore.Datastore
+	primaryKey hmacConfig
+	keysByID   map[string]hmacConfig


it's usually a good idea to encode the hash algorithm/parameters in the key id for later retrieval (password hashing usually does this for example) so that the algorithm / parameters can be rotated alongside the keys themselves.

I.e. it's sha256 now but we decide we need to rotate to sha512 or sha3 etc.

That's why we have the algorithm version byte; we can map from that to the alg used

josephschorr requested a review from a team as a code owner July 8, 2024 21:23

josephschorr marked this pull request as draft July 8, 2024 21:23

github-actions bot added area/datastore Affects the storage system area/tooling Affects the dev or user toolchain (e.g. tests, ci, build tools) labels Jul 8, 2024

jzelinskie reviewed Jul 8, 2024

View reviewed changes

ecordell reviewed Jul 8, 2024

View reviewed changes

josephschorr added 5 commits July 11, 2024 13:53

Add integrity metadata to the relationtuple message

0058ec2

Add integrity information to memdb datastore and start on datastore t…

9f32b35

…ests

Add basic relationship integrity proxy which signs relationships when…

04d63a0

… they are written, and matches hashes when they are read

Add support for relationship integrity to CRDB datastore driver

a75fecd

Test: try with highwayhash to compare performance

2308290

josephschorr force-pushed the relationship-integrity branch from 7ed1e6d to 2308290 Compare July 11, 2024 19:25

github-actions bot added the area/dependencies Affects dependencies label Jul 11, 2024

ecordell reviewed Jul 11, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Relationship integrity #1980

Relationship integrity #1980

josephschorr commented Jul 8, 2024 •

edited by jzelinskie

Loading

jzelinskie Jul 8, 2024

jzelinskie Jul 8, 2024

josephschorr Jul 11, 2024

jzelinskie Jul 8, 2024

josephschorr Jul 9, 2024

jzelinskie Jul 8, 2024

josephschorr Jul 9, 2024

jzelinskie Jul 8, 2024

josephschorr Jul 11, 2024

josephschorr Jul 11, 2024

ecordell Jul 8, 2024

ecordell Jul 8, 2024

vroldanbet Jul 9, 2024 •

edited

Loading

josephschorr Jul 11, 2024

josephschorr Jul 11, 2024

vroldanbet Jul 12, 2024

ecordell Jul 11, 2024

josephschorr Jul 11, 2024

Relationship integrity #1980

Are you sure you want to change the base?

Relationship integrity #1980

Conversation

josephschorr commented Jul 8, 2024 • edited by jzelinskie Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vroldanbet Jul 9, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

josephschorr commented Jul 8, 2024 •

edited by jzelinskie

Loading

vroldanbet Jul 9, 2024 •

edited

Loading