Random number generated exception about conceal HOT 5 CLOSED

I'll try to get one of these devices to repro this. I agree with your point about the hiding of the original exception. I will change it so that the original exception is the cause of the new one. I'll get this fix out today.

We decided to throw rather than not throw since this has security implications and we'd rather not promise that we're generating random numbers if we're not actually generating random numbers. I would rather solve the original cause. My best guess right now without a stack trace is that it is a SELinux violation. I'll put up a version with the fix above, so that we can get a stack trace and debug the root cause.

Are you also getting these violations when running with robolectric. That's strange, because we have robolectric tests in the repo which actually exercises this code. Take a look at SharedPrefsBackedKeyChainTest in javatests/

from conceal.

Hmm, I wouldn't really expect Robolectric to work. Here's a typical Robolectric error on a Mac here:

        Caused by:
        com.facebook.crypto.exception.CryptoInitializationException: java.lang.UnsatisfiedLinkError: no cryptox in java.library.path
            at com.facebook.crypto.util.SystemNativeCryptoLibrary.ensureCryptoLoaded(SystemNativeCryptoLibrary.java:41)
            at com.facebook.crypto.cipher.NativeGCMCipher.encryptInit(NativeGCMCipher.java:54)
            at com.facebook.crypto.CipherHelper.getCipherOutputStream(CipherHelper.java:38)
            at com.facebook.crypto.Crypto.encrypt(Crypto.java:102)
            at PLACE_USED
            ... 2 more

            Caused by:
            java.lang.UnsatisfiedLinkError: no cryptox in java.library.path
                at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1886)
                at java.lang.Runtime.loadLibrary0(Runtime.java:849)
                at java.lang.System.loadLibrary(System.java:1088)
                at com.facebook.crypto.util.SystemNativeCryptoLibrary.loadLibraries(SystemNativeCryptoLibrary.java:51)
                at com.facebook.crypto.util.SystemNativeCryptoLibrary.ensureCryptoLoaded(SystemNativeCryptoLibrary.java:40)
                ... 6 more

Since Robolectric can't load native libraries anyway. Still trying to figure what parts I need to make fake implementations of and drop into place in the test application subclass to make Robolectric able to continue on its way. Real encryption isn't needed there, but not blowing up is.

from conceal.

Ah, the Motorola Solutions crash was it detecting a different copy of the PRNG fix from that Android blog post being installed by some other code. After I added initCause I got this:

E/AndroidRuntime( 9787): Caused by: com.facebook.crypto.exception.KeyChainException: Random number generated
E/AndroidRuntime( 9787):    at com.facebook.crypto.keychain.FixedSecureRandomFix.tryApplyFixes(FixedSecureRandomFix.java:69)
E/AndroidRuntime( 9787):    at com.facebook.crypto.keychain.FixedSharedPrefsBackedKeyChain.getNewIV(FixedSharedPrefsBackedKeyChain.java:79)
E/AndroidRuntime( 9787):    at com.facebook.crypto.CipherHelper.getCipherOutputStream(CipherHelper.java:36)
E/AndroidRuntime( 9787):    at com.facebook.crypto.Crypto.encrypt(Crypto.java:102)
E/AndroidRuntime( 9787):    at PLACE_USED
E/AndroidRuntime( 9787):    ... 16 more
E/AndroidRuntime( 9787): Caused by: java.lang.SecurityException: new SecureRandom() backed by wrong Provider: class OTHER_PACKAGE.PRNGFixes$LinuxPRNGSecureRandomProvider
E/AndroidRuntime( 9787):    at com.facebook.crypto.keychain.FixedSecureRandomFix.tryInstallLinuxPRNGSecureRandom(FixedSecureRandomFix.java:189)
E/AndroidRuntime( 9787):    at com.facebook.crypto.keychain.FixedSecureRandomFix.tryApplyFixes(FixedSecureRandomFix.java:63)
E/AndroidRuntime( 9787):    ... 20 more

The other copy is already a source dependency instead of an AAR dependency, so I can just change it to use Facebook's.

from conceal.

• Our robolectric tests don't actually touch places that load native code. That gets a little bit tricky to test. You'd probably have to find a way to load the x86 binary versions in memory before invoking the Crypto class. We instead have instrumentation tests for those cases which test all of the crypto functions.
  If a class is using Crypto, I suggest you mock out the Crypto class using easy mock or something if you want to run tests against crypto as you have mentioned.
• That's great to know about the crash is solved. I will close out this task with a follow up to add cause to the exception. We have made it a point to not include detailed stack traces in order to minimize oracles about where the encryption failed, but in this case it seems fine to include it. Please re-open if you have other concerns.

from conceal.

#31

from conceal.