Encrypted data will be lost when user upgrades to Android 9 about flutter_string_encryption HOT 4 CLOSED

Are you sure about this?
I've checked the source code of the library and it seems to me that this value is used in a fail-safe way just to add a bit more entropy to seed-generating functions.
I think it won't have any noticeable impact at all and I'm also 99% sure that decryption won't be affected.
If someone is able to test, or has already tested, can they please write here?

from flutter_string_encryption.

I didn't check the source code in more detail yet, I just read the referenced issue description which says "will probably make the encrypted data non forward compatible".

But without even looking at the source codes my assumption was that the hardware id is used to tight the encryption to the device in question. That's how I have used hw id in my earlier projects. I am quite surprised if it is used for some other purposes here. For generating random data?? I am at least interested to know if there is a good reason to use the hardware id. It is user sensitive data anyway so it should be used only if really needed.

from flutter_string_encryption.

Ok I reviewed the code more detaily. The code using serial number is copied from here https://android-developers.googleblog.com/2013/08/some-securerandom-thoughts.html. It is an article written by Android Security Engineer so I guess we can trust what he is doing.

I also noticed that the serial number is not used at all in SDK versions 19 or later. So there should not be any issue after all.

Sorry for invalid bug report, but maybe it was good to verify this.

from flutter_string_encryption.

Thanks for the feedback and following up on the report for Tozny's AES library. For background, there was an Android entropy bug in ancient history, and Google provides a workaround that's incorporated into our library and is still availability for backward compatibility.

To emphasize, we do not use HW ID to tie an encryption key to a particular device, and we have no reason to think that this change will impact encryption or decryption (unless someone is using our library wrong). All of this code is only invoked on older devices as well. Apologies for not replying to the original report earlier.

Longer term, we want to analyze whether any of the backward compatibility code is still necessary; based on whether & how many devices are still using older versions of Android. The AES library would be significantly simpler without that backward compatibility PRNG fix.

from flutter_string_encryption.