Use AES-GCM instead of AES-CBC

[AKushWarrior]

In Hive, HiveAesCipher uses AES-CBC internally. I'm making a case that AES-GCM is a better choice. CBC is slower than GCM, and is less secure. GCM has also been standardized by NIST.

If you choose not to use GCM, you should at least CMAC the ciphertext after the initial CBC encryption. This will ensure message integrity; not using any MAC after AES-CBC leaves you vulnerable to a bit-flipping attack.

https://csrc.nist.gov/publications/detail/sp/800-38d/final https://crypto.stackexchange.com/questions/2310/what-is-the-difference-between-cbc-and-gcm-mode https://crypto.stackexchange.com/questions/3294/why-is-a-mac-needed-with-cbc

[AKushWarrior]

I just noticed the Hive 2.0 issue (#246).

Since this would break all encrypted boxes, maybe the best idea is to bundle a change to encryption in Hive 2.0?

[simc]

Thanks for the suggestion. I'll need to read about the algorithm.

Since this would break all encrypted boxes, maybe the best idea is to bundle a change to encryption in Hive 2.0?

Yes, Hive 2.0 will be perfect for a new encryption algorithm. At first, there will be no encryption since there is still an outstanding issue for LMDB. Also, I need to figure out how to encrypt IndexedDB databases.

[AKushWarrior]

@TheMisir This is still an issue. Encrypted boxes are insecure.

[themisir]

Would you mind migrating this issue to isar/isar (aka: Hive 2.0)?

Also:

• Changing default encryption algorithm might corrupt exists databases
• Devs who wants to use different algorithm can implement their own HiveCipher implementation and use it when opening boxes: Hive.openBox(encryptionCipher: CustomCipherAlg())

[AKushWarrior]

Would you mind migrating this issue to isar/isar (aka: Hive 2.0)?

Also:

• Changing default encryption algorithm might corrupt exists databases
• Devs who wants to use different algorithm can implement their own HiveCipher implementation and use it when opening boxes: Hive.openBox(encryptionCipher: CustomCipherAlg())

I'll copy it to Isar at some point.

We should at least add a note to the Hive README about the issue and provide an AES-GCM/AES-CBC-with-CMAC HiveCipher implementation, which users can plug if they want.

I would also recommend providing a migration tool from one HiveCipher implementation to another (should be pretty simple).

Actually changing the default would break all boxes, so that's a no-go. However, if we are going to claim encryption support, we should provide the tools to actually do so.

[simc]

@AKushWarrior Could you please provide sources that claim AES CBC to be insecure?

[AKushWarrior]

@leisim posted a stackexchange link above. I can go find the papers that back the answers up if you want.

[simc]

@AKushWarrior Sorry I overlooked the links. It is true that CBC does not verify the encrypted message so an attacker can change it without the app noticing. This is not a problem however for databases because we generally do not care if someone changes the database but we want to keep the data in the database safe so nobody can read it.

Edit: Realm for example also uses CBC

[themisir]

What's purpose of strong encryption if the key is stored on the device (persistent storage or memory)? It can be used to decrypt data. Even if you store the key on server-side the key needs to be stored on memory to decrypt contents. Or users can easily intercept incoming packets (using MITM techniques) and get encryption key.

Just asking.

[simc]

@TheMisir Yes someone with physical access / root access to the device can easily decrypt the database but that's almost always the case no matter the encryption algorithm.

WhatsApp for example uses an encrypted database in the external storage to persist it's data between app installs but still protect it from other apps.

[AKushWarrior]

@TheMisir Yes someone with physical access / root access to the device can easily decrypt the database but that's almost always the case no matter the encryption algorithm.

WhatsApp for example uses an encrypted database in the external storage to persist it's data between app installs but still protect it from other apps.

If an agent has root or MITM access, security is screwed. A user who cares about security won't allow those things. On the other hand, security is still important because it's pretty easy to find files on a device; having plaintext files with user data is a no-go.

[AKushWarrior]

@AKushWarrior Sorry I overlooked the links. It is true that CBC does not verify the encrypted message so an attacker can change it without the app noticing. This is not a problem however for databases because we generally do not care if someone changes the database but we want to keep the data in the database safe so nobody can read it.

Edit: Realm for example also uses CBC

If the attacker can change messages in predictable ways, that's an issue. For example: https://en.wikipedia.org/wiki/Bit-flipping_attack. Attackers could test the effects of flipping particular bits. If there is a pattern to the data that is visible from the app (perhaps this is finance data or similar structured private data) a theoretical attacker could wreak havoc.

Regardless, I don't think it hurts to provide GCM as an alternative cipher (even if it's not available by default). It's actually faster than CBC in most cases if AES-NI is available, and the IV is only 12 bytes as opposed to 16. For large amounts of small-size inputs into Hive, the difference in IV size will actually be pretty relevant.

[simc]

If the attacker can change messages in predictable ways, that's an issue.

Just store an additional hash in the database of the data you want to protect and this will never be an issue.

Regardless, I don't think it hurts to provide GCM as an alternative cipher (even if it's not available by default).

The encryption algorithm in Hive is modular so someone can just write a package with a GCM implementation. I don't think it makes sense to provide an "official" implementation at the moment.

It's actually faster than CBC in most cases if AES-NI is available

Unfortunately this is not the case for VM languages afaik. My prediction is that it will be noticeably slower than the current CBC implementation (which is quite optimized for the Dart VM).

[AKushWarrior]

RE hash storage: thats typically what MACs are for. However, Hive doesn't provide an easy way to either hash or MAC verify encrypted boxes. In my original post for this issue, I alluded to this: CBC is usually only considered secure if used in conjunction with a MAC.

It's actually faster than CBC in most cases if AES-NI is available

Unfortunately this is not the case for VM languages afaik. My prediction is that it will be noticeably slower than the current CBC implementation (which is quite optimized for the Dart VM).

This is unfortunately likely. I'm waiting for the day when FFI reaches web so that we can all use OpenSSL instead of reimplementing things in Dart.