Re: ANNOUNCE: "jscryptor: client-side web page encryption" using JavaScript



d wrote:
The MAC is calculated by XORing a hash of the original/decrypted
plaintext with a hash of the key.

This MAC is insecure against known-plaintext attack. If the attacker
knows the (original) plaintext, they can compute the hash of the
plaintext; then if they know the MAC, they can recover a hash of the key
by xor-ing; finally, once they know a hash of the key, they can replace
the plaintext with some other plaintext and adjust the MAC appropriately.

The CFB encryption (especially the use of the MAC as IV) confounds the
last step of the attack, so I don't know whether the whole thing all
together is insecure, but the MAC on its own is insecure. That's a bad
sign, and I don't recommend using a construction with this property.

It would be better to use SHA1-HMAC.

Also, if you ever use the same key for more than one message, then I
think your MAC construction violates confidentiality. Suppose that for
one message, I know the plaintext and I intercept the ciphertext. Then,
as above, I can calculate the hash of the key. Now suppose I intercept a
second ciphertext, corresponding to some unknown plaintext. I can extract
the MAC field from that second ciphertext, xor with the hash of the key,
and learn the hash of the second plaintext. If the second plaintext has
low entropy, then this is enough to recover the second plaintext by using
a dictionary attack. It is also enough to detect repeated plaintexts.

It would be better to use a random IV, rather than one generated
deterministically from the plaintext.

For these reasons, I wouldn't recommend that this construction be used
to protect important data.
.



Relevant Pages