make TOTAL_MEMORY configurable.
tonyg opened this issue · 7 comments
Make TOTAL_MEMORY configurable. As a side-effect, this will permit complete garbage-collection and rebooting of the module as a page runs.
Any update on this? It appears that it's pretty leaky right now which causes really weird behavior on mobile devices after a decent amount of cryptobox() functions are run. I love the library and want to use it in production, but this is a bit of a problem.
Hmm! Are you running bef27c5 or later? Earlier revisions were drastically leaky, but I had hoped to have fixed the leaks as of that revision. It has been some time and I don't remember what my planned approach for making TOTAL_MEMORY configurable was to have been; I'll think on it a little and see what I can come up with. Suggestions welcome.
I've just cross-checked js-scrypt, where the statically-instantiated module has been replaced with a module factory. That seems a sensible approach for this package too; I'll give it a try.
Awesome, thank you! Unfortunately, it appears my problem wasn't fixed. Basically, after a few (say, 100) rounds of encryption/decryption, the result of crypto_box_open() starts to "drift", and is either outputted truncated, with random letters transposed, or with NaCl throwing an error. Reloading the library fixes the issue temporarily, but then it happens again.
I have been trying to come up with a test case that I could submit, but I haven't been able to reproduce it reliably yet. This message is really just a heads up that there might be something weird going on with the library, not a complaint or a request for a fix. Thanks for the awesome work!
Thanks, @alax. That sounds bad! I have had problems in the past running the code on Safari for some reason, with incorrect results coming visible; I wonder if it's the same thing?
Which browser have you been using primarily, by the way?
So far, I haven't run into the issue using desktop browsers (I have been testing on Mobile Safari on iOS 7 and the BlackBerry 10 browser_. Both mobile browsers exhibit the same symptoms of cleartext drift and then complete decryption failure after a seemingly arbitrary (but consistent) number of decryption rounds; it's quite odd. I can produce a test case for you that will reliably fail on any iOS/BlackBerry 10 device, if that would help you out at all. I am sure it would fail on an Android device as well, I just haven't gotten around to testing with one yet.
Right now, the only "fix" for me is to just re-instantiate JS-NaCl for every decryption event. This wasn't even possible until the latest commit, so I really do appreciate the quick response there. But, for obvious reasons it's a pretty terrible solution from a performance standpoint, and it doesn't actually guarantee the output is going to be correct, but at the very least the test cases don't fail using this method.
Ouch, yes that's very odd. I agree that constant reboots are not a viable fix in anything other than the short term. Hmm. Please do post the test case you have; it'll be useful as a starting point. Best start a separate issue, though, I think, describing the problem afresh.