L'HMAC può confermare l'esistenza del messaggio?

Ciò di cui hai bisogno qui è correttamente chiamato hashing randomizzato : concettualmente, una famiglia di funzioni hash sicure, da cui scegli i membri a caso e li usi per hash Messaggio. Tipicamente questi sono implementati come funzioni two-arguement che accettano una "chiave" o "salt" come primo argomento, ma è importante capire che questa "chiave" è (potenzialmente) non intesa per essere segreto -si possono essere rivelati agli avversari.

In generale, i MAC non fanno buoni hash randomizzati, perché l'obiettivo di sicurezza MAC standard è per le chiavi segrete -keys conosciute solo dalle parti oneste e non dagli avversari. Ma HMAC nonostante il nome è più di un semplice MAC, è costruito su una funzione di hash sicura, quindi può essere usato entrambi come MAC e come funzione di hash randomizzata.

Quindi la risposta breve è sì, ma in questo caso non essere confuso dal nome HMAC; HMAC funziona qui perché è una buona funzione di hash , non perché è un buon MAC. E se hai una buona funzione di hash non hai bisogno di HMAC per questo- hash(salt || msg) dovrebbe funzionare bene. Userei HMAC, tuttavia.

Quindi, se ho capito bene, gli host A e B hanno un'informazione e A vuole sapere se B lo possiede ancora. Perché non chiedere semplicemente a B di inviare i dati ad A?

Se i dati sono di grandi dimensioni, potresti volerli hash e inviare B hash a A. Senza i dati, B non può mai fare l'hash corretto.

Tuttavia, B potrebbe generarlo una volta, memorizzare l'hash corretto e buttare via i dati. Se vuoi impedire questo, puoi usare un sistema di risposta alle sfide in cui hai A un numero casuale (con un CSPRNG), inviarlo a B, e B deve cancellare i dati insieme al numero casuale e inviare il risultato a R. Poiché A ha sia la risposta corretta sia il numero, può eseguire la stessa operazione e convalidare il risultato.

Se si utilizza un HMAC con il numero casuale ei dati come i due parametri, penso che dovrebbe essere sicuro. Tuttavia, dal momento che stiamo inventando la nostra crittografia qui, potresti chiedere il link per verificare che quando si calcola hash = HMAC(number, data) e memorizzando sia l'hash che il numero (e forse i valori intermedi dell'operazione HMAC), non è possibile calcolare l'hash corretto per un nuovo numero senza i dati originali.

Mi chiedo perché ne hai bisogno, comunque. Non riesco a pensare a un posto dove questo è attualmente in uso, quindi mi chiedo se non c'è semplicemente una soluzione esistente al problema che stai cercando di risolvere, invece di fare questo complicato sistema con "il continuo possesso delle informazioni".

Oh e Keccak non ha niente a che fare con questo. Gli HMAC prevengono gli attacchi dell'estensione di lunghezza hash, non è necessario utilizzare una funzione di hash specifica per quello. SHA2 e SHA3 stanno bene entrambi. Non vi è inoltre alcun punto di hashing di una versione crittografata. Perché preoccuparsi della crittografia? Sembra un po 'come si sta facendo zuppa cripto; -)

Penso che la soluzione più semplice per te sia pre-calcolare un insieme di hash di offset + lunghezza e quindi inviare una richiesta con una di queste coppie di offset e di lunghezza ogni tanto.

Qualunque cosa tu faccia, devi eseguire le stesse operazioni in anticipo se prevedi di eliminare i dati che stai caricando, e questo metodo impone il carico più basso sul provider di archiviazione.