From 91097382399a31fc94d0ac30b0dc3c1cfbeb4779 Mon Sep 17 00:00:00 2001 From: noemi3 Date: Thu, 9 Jul 2020 17:21:20 +0200 Subject: [PATCH] add reporting --- documentazione.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/documentazione.md b/documentazione.md index 85b37cb..14906c5 100644 --- a/documentazione.md +++ b/documentazione.md @@ -62,6 +62,37 @@ Dalla chiave rak è possibile generare la chiave rvk e la chiave tck_0, dalle qu ### Report +Un utente che vuole caricare il proprio report del periodo compreso tra `j1` e `j2`, lo farà nel seguente modo: + +``` +report ← rvk || tck_{j1-1} || le_u16(j1) || le_u16(j2) || memo +``` + +dove `memo` è una stringa di byte di lunghezza variabile che va da 2 a 257 byte. +Inoltre si utilizza il rak per produrre una firma`sig` per il report `report` e verrà mandata la concatenazione di `sig` || `report` al server. + +Chiunque può verificare l'integrità della sorgente e ricavare il tcn tramite sig, report e rvk, per poi confrontare questo tcn ottenuto con le proprie osservazioni. + +``` +tck_j1 ← H_tck(rvk || tck_{j1-1}) # Ratchet +tcn_j1 ← H_tcn(le_u16(j1) || tck_{j1}) # Generate +tck_{j1+1} ← H_tck(rvk || tck_{j1}) # Ratchet +tcn_{j1+1} ← H_tcn(le_u16(j1+1) || tck_{j1+1}) # Generate +... +``` + +**non so se mettere o no questa parte di codice** + +Si noti che il tcn deriva dal `tck_1{j1-1}`che non è incluso nel report, perchè il destinatario non può verificare se è associato al rvk. +Se la verifica del client non è importante, il server, in modo arbitrario, può rmuover i 64 byte finali da ciascun report. + + + + + + + + ## Implementazione del protocollo per la JMV