A client wishes to verify that a server holds some data: checking the server's data integrity.
Easiest would be for the server to send a full copy of the data to the client, and the client can check the received data with a known good version. However this consumes a lot of bandwidth.
What doesn't quite work is for the server to return a "famous" cryptographic checksum, e.g., SHA-256, of the data. The server could have precalculated the checksum and cached it before its copy of the data went corrupt. There is no way for the client to be sure that the checksum was calculated recently.
Better is for the client to request a MAC, a keyed hash of the data, providing an unpredictable key. This way the server must look at the data in its entirety again. The construction of the MAC matters. HMAC is probably good, H(data || key) is bad because the server could freeze the computation of the MAC just before the key bits. Keccak(key || data) is probably good.
If the client wants to save on data storage of the "known good copy", it could precalculate the MACs for some number of private keys in advance. Each private key can be used only once.
It is curious that this seems a MAC application in which the key may travel over the clear.
No comments :
Post a Comment