fixed report

This commit is contained in:
noemi3 2020-07-10 17:30:02 +02:00
parent 9109738239
commit f6bbded63a

View File

@ -62,36 +62,16 @@ 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:
Quando viene richiesto di caricare i dati dell'utente, è possibile eseguire l'upload di un report compatto. Infatti grazie alla derivazione deterministica, è possibile inviare tutti gli identificativi utilizzati nel periodo `j1` e `j2`, caricando unicamente la rvk, tck_{j-1}, e i due indici `j1` e `j2`. Di seguito è illustrato come costruire il report:
```
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.
Inoltre si utilizza il rak per produrre una firma `sig` per il report e verrà inviata al server la concatenazione di sig e report.
Poichè la rvk è contenuta all'interno del report, chiunque può verificare l'integrità del report e ricavare i vari.