# It's safe to store a known value (for checking) next to the actually encrypted values

The high level details of the encryption I'm using is:

• AndroidKeyStore create/store RSA key
• AES key is created and wrapped with RSA/ECB/PKCS1Padding
• Encrypted AES is saved to disk.
• Data is encrypted with AES/GCM/NoPadding and saved to disk.
• Every encryption operation generates a new initialization vector from the platform secure random. Those are also saved to disk with their data.

The algorithm/transformation used are limited by the platform.

There are known issues on the AndroidKeyStore forgetting keys and I would like to save a known "lorem ipsum" data encrypted on first run. This known data would later be used during initialization to check the consistency of the keys and provide proper status for the system.

So my question: is it safe to store this known hard-coded value next to the real values, or with that I'm leaking everything and making it easy for someone to decrypt the real values?

• As long as RSA padding creates randomness you should be fine. Do you have enough space for "magic word"? – VovCA Aug 1 '18 at 18:01

Note that you may want to use RSA-OAEP or RSA-KEM rather than PKCS#1 to avoid padding related attacks (RSA-OAEP should be directly available in Java / Android and is therefore recommended, but please do check with the KeyStore implementation and the targetted runtimes to be sure).
• Thanks a lot for the answer. Unfortunately I can't directly reproduce the crashes, I only see them on the error logs. It all seems that RSA got extracted and AES unwrapped. And then on the moment of decrypting the data the crashes happen with AEADBadTagException: error:1e000065:Cipher functions:OPENSSL_internal:BAD_DECRYPT. So what I'm doing is just running an actual data decryption earlier on to check if the real decryption will pass later on. – Budius Aug 2 '18 at 7:28
• Yeah, I know there are / were some issues with the KeyStore and the available algorithms from StackOverflow, hence the hint to test. Hopefully it is still a helpful answer. If you want to test the key AES key explicitly you could include a Key Check Value next to the ciphertext (a block of zero's encrypted with the AES key, then take the X leftmost bytes). However, note that this won't identify the right key if the KCV itself can be changed. AES/GCM is not affected by this because it starts the counter value at $IV \| 0^{31}1$. – Maarten Bodewes Aug 2 '18 at 16:37