Feature #1648

Notary support in Core / ICTD

Added by n8fr8 over 4 years ago. Updated about 4 years ago.

Status:NewStart date:07/28/2013
Priority:HighDue date:
Assignee:harlo% Done:


Target version:Back Burner


We need to re-implement the hash-only submission aspect of our previous server into a new "Notary" capacity, both as a feature of core, and something provided by ICTD files.

InformaCore should be able to automatically ping configured notaries with hash values of media when it is captured. This is to get as close to "this hash existed at this date/time, sent from this IP" as we can get. Notaries can be URLs, Email addresses, or SMS phone numbers.

The ICTD definition should include a {Notaries:[{}]} section just as it does Repositories. I think Notaries should be independent of Repositories, in the ICTD definition, however, they may be coordinated on the back-end.

I could imagine, for instance, the IBA setting up an "SMS Notary", so {Notary: { Type: "SMS", Destination: "+441125551212"}. In this case, the InformaCore would send an SMS of a media hash as soon as that media was captured, to the indicated phone number. When the IBA receives the SMS, they can save that hash value, and later use it to verify against a submission sent in via their Globaleaks instance.

GLSP on the other hand, may just want an email {Notary {Type: "Email", Destination: ""}}

Martus and/or a Globaleaks back-end, could support an onion-based ping type URL: {Notary {Type:"URL", Desitation: "http://12398djaslkd1.onion/icnotary/"}}

We could also consider providing a default notary option using a Distributed Hash Table, Bitcoin, or other difficult to refute public service.


#1 Updated by harlo over 4 years ago

yes! awesome. on it.

#2 Updated by n8fr8 over 4 years ago

  • Target version changed from InformaCam - Public Preview v1 to InformaCam - Public Beta v1

#3 Updated by n8fr8 about 4 years ago

  • Target version changed from InformaCam - Public Beta v1 to InformaCam - APP Public Beta v2

#4 Updated by n8fr8 about 4 years ago

  • Target version changed from InformaCam - APP Public Beta v2 to Back Burner

#5 Updated by ocdavid about 4 years ago

I might like to work on this (on the server side). Any effort I make would not impact anyone on the current team - there's too much to do already. But I really like this lightweight idea, so I'd like to try. Try = write up a paper for discussion == no charge to the project(s).

I have three question though:

1. What method do we currently use to get a unique identifier for a specific device that can transcend application reinstallations and is not sensitive to which SIM card installed?

2. Would it be permissible to have an "initial registration phase" (one-time) that (a) requires a low-bandwidth network connection and (b) uses Google Android Cloud to Device Messaging (AC2D)?

3. Is there value in this being more like an actual notary public, while still staying close to hash-only? That is, do we want to have 3rd party verification that image X was acquired on device Y at date/time Z? Or is it more important - given the other ways we have to provide such verification -to keep this as ultra-lightweight as possible?

#6 Updated by ocdavid about 4 years ago

Oh, and I would try not to use digital signatures in the formal PKI sense, to stay away from the cert hierarchy issues.

Also available in: Atom PDF