first implementation of the teamchain auditor #13544

maxtaco · 2018-08-31T19:43:22Z

the goal of the teamchain auditor is to prevent the server from pulling off an "odd/even" attack. That is, when showing team acme to
alice, the server sends even merkle roots, that show view A of the team. When showing team acme to bob, the server sends odd
merkle roots, that show view B of the team. Where A and B might not agree at all. The server can hide these patterns in the
merkle tree in arbitrary ways, with the goal to get alice and bob to see two different ideas of the same team, without forking
the merkle tree globally.
our approach is for alice and bob to make random "probes". probe the time before the team was created, the time after the
team was created, and ensure a consistent view.
after 1000 new merkle roots, the audit repeats, with alice and bob idependently auditing the recent roots.
for now, we've hardcoded parameters, but we'll likely want to tune them in the future.
write all audit results to disk cache.
also, while we're there, clean up the merkle client "first root with skip" logic

maxtaco · 2018-09-04T14:23:33Z

There's a bug somewhere in here that CI just found, likely in kbweb, so I added more debugging here: https://github.com/keybase/keybase/commit/3b566ab66f8290f5d39e44ff0a3d6e763883d3d0

go/teams/audit.go

heronhaye · 2018-09-05T20:18:55Z

ah, I confused math/rand with crypto/rand, you're right.

…

On Wed, Sep 5, 2018 at 4:17 PM Maxwell Krohn ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In go/teams/audit.go <#13544 (comment)>: > + return nil + } + for _, tuple := range probeTuples { + m.CDebugf("preProbe: checking probe at merkle %d", tuple.merkle) + if tuple.team != keybase1.Seqno(0) || !tuple.linkID.IsNil() { + return NewAuditError("merkle root at %v should have been nil for %v; got %s/%d", + tuple.merkle, history.ID, tuple.linkID, tuple.team) + } + } + return nil +} + +func randSeqno(lo keybase1.Seqno, hi keybase1.Seqno) (keybase1.Seqno, error) { + rng := hi - lo + 1 + rngBig := big.NewInt(int64(rng)) + n, err := rand.Int(rand.Reader, rngBig) thanks for checking this, though I believe it is! — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#13544 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AbYebpFIht9a3Q_iuR2EFvtylQyuYuCRks5uYDE_gaJpZM4WVw2d> .

go/teams/audit.go

go/teams/ftl.go

mlsteele · 2018-09-05T15:08:25Z

go/teams/audit.go

 // ProbabilisticMerkleTeamAudit runs an audit on the links of the given team chain (or subchain).
 // The security factor of the audit is a function of the platform type, and the amount of time
 // since the last audit. This method should use some sort of long-lived cache (via local DB) so that
 // previous audits can be combined with the current one.
-func ProbabilisticMerkleTeamAudit(m libkb.MetaContext, id keybase1.TeamID, startMerkleSeqno keybase1.Seqno, chain []SCChainLink) (err error) {
-	return errors.New("stubbed out")
+func (a *Auditor) AuditTeam(m libkb.MetaContext, id keybase1.TeamID, isPublic bool, headMerkle keybase1.MerkleRootV2, chain map[keybase1.Seqno]keybase1.LinkID, maxSeqno keybase1.Seqno) (err error) {


Comment ProbabilisticMerkleTeamAudit -> AuditTeam

Does subchain in the comment mean slice like for users or pick and choose like high set?

comment to remember what these args are

headMerkle: merkle root claimed by the first link in the team

maxSeqno: seqno of the tail of the team sigchain

no, it's just the most recent chain links we got from the server.

protocol/avdl/keybase1/teams.avdl

go/teams/audit.go

go/libkb/merkle_client.go

go/teams/audit.go

maxtaco · 2018-09-06T13:26:27Z

@mlsteele / @heronhaye ok or do you guys want to keep reviewing?

- the goal of the teamchain auditor is to prevent the server from pulling off an "odd/even" attack. That is, when showing team acme to alice, the server sends even merkle roots, that show view A of the team. When showing team acme to bob, the server sends odd merkle roots, that show view B of the team. Where A and B might not agree at all. The server can hide these patterns in the merkle tree in arbitrary ways, with the goal to get alice and bob to see two different ideas of the same team, without forking the merkle tree globally. - our approach is for alice and bob to make random "probes". the probe the team before the team was created, the time after the team was created, and ensure a consistent view. - after 1000 new merkle roots, the audit repeats, with alice and bob idependently auditing the recent roots. - for now, we've hardcoded parameters, but we'll likely want to tune them in the future. - write all audit results to disk cache.

@mlsteele

- the goal of the teamchain auditor is to prevent the server from pulling off an "odd/even" attack. That is, when showing team acme to alice, the server sends even merkle roots, that show view A of the team. When showing team acme to bob, the server sends odd merkle roots, that show view B of the team. Where A and B might not agree at all. The server can hide these patterns in the merkle tree in arbitrary ways, with the goal to get alice and bob to see two different ideas of the same team, without forking the merkle tree globally. - our approach is for alice and bob to make random "probes". the probe the team before the team was created, the time after the team was created, and ensure a consistent view. - after 1000 new merkle roots, the audit repeats, with alice and bob idependently auditing the recent roots. - for now, we've hardcoded parameters, but we'll likely want to tune them in the future. - write all audit results to disk cache. - merge by hand since github is down - also @mlsteele might have further comments

@mlsteele

- the goal of the teamchain auditor is to prevent the server from pulling off an "odd/even" attack. That is, when showing team acme to alice, the server sends even merkle roots, that show view A of the team. When showing team acme to bob, the server sends odd merkle roots, that show view B of the team. Where A and B might not agree at all. The server can hide these patterns in the merkle tree in arbitrary ways, with the goal to get alice and bob to see two different ideas of the same team, without forking the merkle tree globally. - our approach is for alice and bob to make random "probes". the probe the team before the team was created, the time after the team was created, and ensure a consistent view. - after 1000 new merkle roots, the audit repeats, with alice and bob idependently auditing the recent roots. - for now, we've hardcoded parameters, but we'll likely want to tune them in the future. - write all audit results to disk cache. - merge by hand since github is down - also @mlsteele might have further comments

@mlsteele

- the goal of the teamchain auditor is to prevent the server from pulling off an "odd/even" attack. That is, when showing team acme to alice, the server sends even merkle roots, that show view A of the team. When showing team acme to bob, the server sends odd merkle roots, that show view B of the team. Where A and B might not agree at all. The server can hide these patterns in the merkle tree in arbitrary ways, with the goal to get alice and bob to see two different ideas of the same team, without forking the merkle tree globally. - our approach is for alice and bob to make random "probes". the probe the team before the team was created, the time after the team was created, and ensure a consistent view. - after 1000 new merkle roots, the audit repeats, with alice and bob idependently auditing the recent roots. - for now, we've hardcoded parameters, but we'll likely want to tune them in the future. - write all audit results to disk cache. - merge by hand since github is down - also @mlsteele might have further comments

mlsteele

I think this makes sense. Seems like a lot of complexity, which might stem from storing the history that way. Has anyone written anything about the probabilities of discovering an attack this way?

maxtaco · 2018-09-07T19:16:12Z

No, we should try to come up with a proof of some sort given my back-of-the-envelope calculations. The logic is similar to Miller-Rabin primality testing.

maxtaco requested review from mlsteele and heronhaye August 31, 2018 19:43

maxtaco mentioned this pull request Sep 4, 2018

get chat encryption and decryption to work via FTL #13569

Merged

heronhaye reviewed Sep 5, 2018

View reviewed changes

go/teams/audit.go Outdated Show resolved Hide resolved

heronhaye reviewed Sep 5, 2018

View reviewed changes

go/teams/audit.go Outdated Show resolved Hide resolved

heronhaye reviewed Sep 5, 2018

View reviewed changes

go/teams/audit.go Show resolved Hide resolved

mlsteele reviewed Sep 5, 2018

View reviewed changes

maxtaco force-pushed the maxtaco/CORE-8466 branch from 1553855 to 5bc6951 Compare September 6, 2018 02:18

maxtaco added 7 commits September 6, 2018 11:50

fix lint

acfd357

comments from review about comments

a3c02f7

comments from review

178c315

comments from review comments

20adc6c

comments from review

625c39a

comments from review

371a387

maxtaco force-pushed the maxtaco/CORE-8466 branch from 36d124e to 371a387 Compare September 6, 2018 15:51

mlsteele approved these changes Sep 7, 2018

View reviewed changes

maxtaco closed this Sep 28, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

first implementation of the teamchain auditor #13544

first implementation of the teamchain auditor #13544

maxtaco commented Aug 31, 2018 •

edited

Loading

maxtaco commented Sep 4, 2018

heronhaye commented Sep 5, 2018 via email

mlsteele Sep 5, 2018

mlsteele Sep 5, 2018

mlsteele Sep 5, 2018

maxtaco Sep 6, 2018

maxtaco commented Sep 6, 2018

mlsteele left a comment

maxtaco commented Sep 7, 2018 •

edited

Loading

first implementation of the teamchain auditor #13544

first implementation of the teamchain auditor #13544

Conversation

maxtaco commented Aug 31, 2018 • edited Loading

maxtaco commented Sep 4, 2018

heronhaye commented Sep 5, 2018 via email

mlsteele Sep 5, 2018

Choose a reason for hiding this comment

mlsteele Sep 5, 2018

Choose a reason for hiding this comment

mlsteele Sep 5, 2018

Choose a reason for hiding this comment

maxtaco Sep 6, 2018

Choose a reason for hiding this comment

maxtaco commented Sep 6, 2018

mlsteele left a comment

Choose a reason for hiding this comment

maxtaco commented Sep 7, 2018 • edited Loading

maxtaco commented Aug 31, 2018 •

edited

Loading

maxtaco commented Sep 7, 2018 •

edited

Loading