An encryption format offering better security, performance and ease of use than PGP. File a bug if you found anything where we are worse than our competition, and we will fix it.
41
stars
10
forks
source link
Key commitment to protect AEAD against malicious keys and ciphertexts #101
AEAD schemes are vulnerable to an invisible salamander attack where one ciphextext may decrypt to many different plaintexts depending on the key used. The process involves creating at least two different keys and manipulating the ciphertext blocks such that desirable decryption is obtained. There will be a lot of random noise in the messages but with a bit of brute forcing for suitable keys it is possible to find keystreams that produce for a few bytes two messages so that the garbage is ignored (the original paper demonstrated making the data seem either as JPEG or BMP, depending on a few header bytes that would skip the other image and the rest of the garbage). The attack applies to ChaCha20-Poly1305 which is employed by Covert, as well as to AES-GCM and other AEAD constructs.
Covert should probably implement a key commitment header that contains a 12-byte hash of the file key. This avoids the aforementioned exploit (that does affect all other kryptographic software based on AEAD where keys may be chosen maliciously), and it could also make testing for recipient keys a bit easier, not having to brute force block0 location and size, as is currently done. Only after a matching key is found, does one need to go looking for block0. Adding this would be a breaking change to all existing users. We can implement legacy mode to also support the old format for now, but that would be removed prior to 1.0 release.
Normally the recipient controls the keys, so this is not an issue, but there are a number of cases where it can be.
AEAD schemes are vulnerable to an invisible salamander attack where one ciphextext may decrypt to many different plaintexts depending on the key used. The process involves creating at least two different keys and manipulating the ciphertext blocks such that desirable decryption is obtained. There will be a lot of random noise in the messages but with a bit of brute forcing for suitable keys it is possible to find keystreams that produce for a few bytes two messages so that the garbage is ignored (the original paper demonstrated making the data seem either as JPEG or BMP, depending on a few header bytes that would skip the other image and the rest of the garbage). The attack applies to ChaCha20-Poly1305 which is employed by Covert, as well as to AES-GCM and other AEAD constructs.
Covert should probably implement a key commitment header that contains a 12-byte hash of the file key. This avoids the aforementioned exploit (that does affect all other kryptographic software based on AEAD where keys may be chosen maliciously), and it could also make testing for recipient keys a bit easier, not having to brute force block0 location and size, as is currently done. Only after a matching key is found, does one need to go looking for block0. Adding this would be a breaking change to all existing users. We can implement legacy mode to also support the old format for now, but that would be removed prior to 1.0 release.
Normally the recipient controls the keys, so this is not an issue, but there are a number of cases where it can be.