1

The question is, if a document that is collaboratively edited, one user per time, could be digitally signed by every editor before it is passed to the next editor. And if yes, could the final receiver use the public keys of every editor in reverse order to verify that the document was edited by the right editor and in the right order?

My guess is that, using some blockchain technique maybe the Hash pointer could help to achieve that, since the latest Hash pointer would include the hash of the hash blocks of every block, therefore every editor until this time. Is there any kind of software out there already that offers that feature?

In case you need an example to get the idea behind the question image this scenario. A teacher has given a task to a group of three students, all of them write to a notepad, the first one that finishes his part opens a .doc file pastes the content, signs the document and pass it to the second one who finishes, he does the same, and then the final student receives the doc, also pastes his content, signes it and then sends it to the teacher, who have the pubic keys of the students to verify the document editors.

As you understand this could also help each editor to be sure that he is not editing a tampered document.

Any thoughts on that would be much appreciated.

  • Second user is then signing their own version of the document or also the version received by the first user? It seems all you need is an ability to sign an archive, with each user just archiving all docs and sending them onwards. – domen Jun 07 '19 at 15:24

2 Answers2

1

ThoriumBR answer provides a neat solution about how a system with the desired properties could work. However, it is quite crude for the students. You would ideally want an application built upon that that abstracted all the storing prior versions and applying the patches.

Rather than creating a new program for this, I would encourage using a version controol system like Git or Mercurial, that already handle storing files and support attaching digital signatures. This greatly simplifies the task (as there are already tools and documentation) and also provides knowledge on tools they may use later (as opposed to a teacher-specific tool). I would recommend that the teacher provides the server on which they will work, so that he can place the right configuration, such as not allowing history-rewriting, automatically rejecting unsigned commits or even non-fast-forwards.

Actually the usage of digital signatures is not that relevant here, as the teacher will probably trust the server logins, but it's a good exercise anyway.

In any case, the real problem for a teacher would not be that the digital signatures are right, but the social one of each student doing its part and not colluding to give another student some changes they were not supposed to provide or even share passwords and digital certificates with their peers.

Ángel
  • 17,578
  • 3
  • 25
  • 60
  • The teacher-students scenario was just an example, but thanks for introducing me to the Git digital singing features. –  Jun 08 '19 at 04:11
0

Yes, it can be done. You will need public keys and patches.

Student A create original.txt, sign it, and send it to Student B. In turn, Student B checks the signature, edits this document, uses diff to create a patch, signs the student_b.patch and sends it along with original.txt.

Student C checks all signatures again, and if they validate applies student_b.patch to original.txt, edits it, creates a patch of its own, signs the patch and sends original.txt, student_b.patch and student_c.path to the teacher.

Teacher verifies the signatures of each file, and if they are validated, applies all patches in order. Done.

This way you can guarantee that each section was indeed edited by the intended editor, and nobody down the chain can alter the original file or its predecessor patches without invalidating the signature.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • 1
    `diff` patches don't guarantee a particular order, I think you'd probably want to sign the original text and previous diffs as well. – AndrolGenhald Jun 07 '19 at 16:50
  • I haven't expressed myself well enough. The idea is original + patch -> file2 -> patch -> file 3... The problem is that user 5 will have to apply 4 patches before editing. Users will patch the previous full version against its modifications and sign the patch. Anyone down the chain can generate all intermediate files, and patch against this intermediate. No need to sign the result, as you have the patches and signatures. – ThoriumBR Jun 07 '19 at 17:11
  • Right, but if student B changes line 10 and creates & signs a patch, then sends it on to student C, who edits line 20 and creates & signs a patch, the signatures don't guarantee any particular order. You could say that student C's edit came first and the signatures would still be valid. – AndrolGenhald Jun 07 '19 at 18:08
  • Each student should sign both the initial file (which may itself be composed of a prior file plus a patch) and its own patch. – Ángel Jun 08 '19 at 00:09
  • @ThoriumBR Thank you for the detailed answer I will soon try to implement this and will come back with the results. –  Jun 08 '19 at 04:14