2
$\begingroup$

We are developing an iOS app which employs Shamir Secret Sharing algorithm. We made all possible steps users can trust us. We can't remember their secrets nor we can save encoded fragments. But they still may not trust us with randomness. Is there any cryptographic method how user can verify we are using random number generator honestly and have no malicious interests?

$\endgroup$
  • 2
    $\begingroup$ In the end the user must trust the app developer... Code is too complex to fully trust. Having code reviews and some way to securely deliver the code to the device does help; security isn't black or white. $\endgroup$ – Maarten Bodewes May 9 '18 at 21:52
  • $\begingroup$ If there's sharing going on, is it possible for the user to supply the randomness? I guess that you still can't prove that the app would use it though. $\endgroup$ – Paul Uszak May 9 '18 at 22:50
  • $\begingroup$ Yes. User can supply the randomness. I was also thinking this way. $\endgroup$ – tomikk May 10 '18 at 13:30
  • $\begingroup$ ...I was also thinking this way. If there is some way how user can supply his own randomness and then verify on different machine that we have used it. $\endgroup$ – tomikk May 10 '18 at 13:36
  • $\begingroup$ Literally 1000s of truly random bits are generated from sensor noise when you take a low light photo on a webcam/phone. There's your user randomness. It's a huge TRNG built into every phone and most laptops. I fear verifying it's use is impossible. $\endgroup$ – Paul Uszak May 10 '18 at 20:39
4
$\begingroup$

Nothing you show the user within the app could prove that the numbers were truly generated randomly and that the numbers weren't leaked maliciously or accidentally.

In general, you could make your application (or the module that does the cryptography, assuming it's built into a separate binary like a library or an executable used by the main app) open source and use a reproducible/deterministic build process so that users can compile the source themselves and verify that it matches what they've installed. I'm not sure how feasible or convenient this may be on the iOS ecosystem though. (Users might need a rooted phone to be able to view the app's binary installed from the app store, etc.)

| improve this answer | |
$\endgroup$
1
$\begingroup$

A real-life example that's relevant is Diceware, where users generate strong, uniform random passphrases by rolling dice and looking the results up in a numbered wordlist. Diceware's virtue is precisely that it's understandable and auditable by people who grasp very little beyond the elements of probability theory. But of course it doesn't wholly remove the requirement that the user audit or trust the cryptography because the passphrase still has to be input into some software.

So one thing you could do is offer the users the option to enter random inputs that are under their control, like dice rolls, passphrases, or the old PGP trick of asking them to mash keys "at random" on the keyboard and measure the timings. The program would then apply a key derivation function (salted with values from the system RNG) to these inputs to obtain a master key or seed, and drive the random choices off that. There are some challenges that I think you would need to solve, like:

  • User experience. None of this sounds awesome for usability, to say the least.
  • Depending on the details of the problem, whether to use a password-based key derivation function or a fast one like HKDF.
| improve this answer | |
$\endgroup$
  • $\begingroup$ This isn't really the issue though. There are many ways for the user to enter strong entropy into an app (simply take a low light photo). This issue is that the app can just ignore that input and do it's own thing anyway. Look the lies and deceit that Google uses to track users. Apps have form on this, especially if there is financial or law enforcement encouragement. $\endgroup$ – Paul Uszak May 10 '18 at 11:46
  • $\begingroup$ Exactly. Those user inputs may fool inexperienced user but not experienced one who knows we can just ignore all user inputed data and used our own non-random. $\endgroup$ – tomikk May 10 '18 at 13:37
  • $\begingroup$ @PaulUszak: I thought of that while I was writing this response. What I concluded in the end is that the analogy to Diceware still is valuable in this context. The same criticism could be raised of Diceware—why bother rolling dice to come up with a strong passphrase when the program that you enter this passphrase into might be backdoored? The answer is it eliminates one, not all things that could go wrong for the user. And don't forget that the one case we do know of a secret NSA cryptographic backdoor is an RNG; if there's any place where such procedure is merited, this might be one. $\endgroup$ – Luis Casillas May 10 '18 at 19:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.