Hacker News Reader

Comment by swordswinger12 | Hacker News Reader

Can you describe your file encryption procedure? In the Meta::Chunk class the 'encrypt' function only computes AES-CBC with no MAC, but there are calls to compute_strong_hash at other points in the library. There are references to a (non-cryptographic) Rabin hash as well as SHA2-224 and SHA3-224 in these functions - which is used for ciphertext authenticity and integrity?

View on HN

During the indexing procedure, the value of SHA3-224(AES256(data)) is computed for each chunk.

Then, the list of these hashes is placed into Meta structure. After that, this Meta is ECDSA-signed using a EC point, decoded from A-type secret.

Any other type of secret contain the public part of EC point and can verify the signature.

So is there a per-chunk MAC, or do you rely on the signed hashes of ciphertext for the integrity and authenticity of each chunk?

Actually, there is per-chunk HMAC support in the protocol and present revisions add HMAC for each chunk into Meta: https://github.com/Librevault/librevault-common/blob/master/...

This HMAC is computed over plaintext chunks and used to determine, if we already have this chunk in database (because of random IV we get different hash of ciphertext every time), not for verification.

And what is wrong about verifying integrity and authenticity by hash-then-sign?

Maybe nothing, but it's just kind of a weird, nonstandard way of doing things. Also it's not immediately obvious to me that your method meets modern security definitions like IND-CCA2.

Reply on news.ycombinator.com