SJCL – Stanford JavaScript Crypto Library

Re:SJCL – Stanford JavaScript Crypto Library by gbrown_ on Wednesday March 08, 2017 @01:28PM (#13822360)

For someone not really familiar with javascript could someone explain how sensitive information is removed from memory when no longer needed? Does the runtime expose semantics to ensure memory is zeroed?

Also given javascript is garbage collected are there concerns about timing attacks? Or can you prevent the GC from running in critical sections like Go (I assume Java offers this too)?

[ Parent | on HN ]

Re:SJCL – Stanford JavaScript Crypto Library by nerdponx on Wednesday March 08, 2017 @01:34PM (#13822409)

This is my question as well. I've seen plenty of advice about how Python is a bad choice for any crypto application because it's almost impossible to secure Python's memory. Is JS different somehow?

[ Parent | on HN ]

Re:SJCL – Stanford JavaScript Crypto Library by ms7 on Wednesday March 08, 2017 @01:35PM (#13822418)

I can't answer your questions with certainty, but for those who can, could ES6 WeakMap address these two things?

[ Parent | on HN ]

Re:SJCL – Stanford JavaScript Crypto Library by bgran on Wednesday March 08, 2017 @02:03PM (#13822651)

WeakMap just allows you to tell the GC "don't hold on to this memory just because I'm using it as a key in this Map" -- it doesn't let you tell the GC what to actually do with the memory.

[ Parent | on HN ]

Re:SJCL – Stanford JavaScript Crypto Library by stevens32 on Wednesday March 08, 2017 @02:16PM (#13822789)

Couldn't buffers be used for explicit memory control? I think that was how emscripten implemented memory management

[ Parent | on HN ]