So, supposing that no other mechanism is available: Take out the identity key from its Faraday cage, sign a statement of which device keys are good and which are compromised, and publish that statement. (And then hide the long-term key away again.)
Same identity afterwards. On Mon, Jan 5, 2015 at 10:07 PM, [email protected] <[email protected]> wrote: > What happens in David's formulation if one were to need to revoke one > device? > > One downside of Trevor's prefered formulation is that loss of control of one > device means restart one's identity from scratch.... > > On Mon, Jan 5, 2015 at 10:03 PM, David Leon Gil <[email protected]> wrote: >> >> On Mon, Jan 5, 2015 at 4:18 PM, Trevor Perrin <[email protected]> wrote: >> > The most practical approaches are probably either synchronizing the >> > identity key between devices, or using it to sign device keys. Either >> > way, adding a new device might increase communication in (f), since >> > Alice might have to retrieve additional device-specific prekeys, >> > and/or signed device keys. >> >> There is no need for an "identity key" to sign anything except an >> initial device key. Just chase cross-signatures back to a >> distinguished (by some flag) identity key that is stored offline, and >> use a hash of that as the fingerprint: >> >> xsign(device0t0, identity) >> xsign(device0t0, device1t0) >> xsign(device0t1, device2t0) >> >> chase_fingerprint(device2) == hash(identity) >> >> (Many thank to Yan for suggesting this approach to stable >> fingerprints, though I don't know that she endorses it.) >> >> This neatly avoids exposing any long-term keys to additional risk of >> compromise. >> _______________________________________________ >> Messaging mailing list >> [email protected] >> https://moderncrypto.org/mailman/listinfo/messaging > > _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
