RunJS
projects.lukehaas.me
projects.lukehaas.me
AES-CBC requires a random IV to be used as a nonce on a per-message basis, otherwise the entire scheme breaks. The toy example given on this website uses the deprecated Node.js createCipher [2] API which does not take such an IV. In fact, the docs and runtime even warn that using CBC mode with the createCipher API is dangerous!
As the code is currently written, an attacker observing multiple encrypted messages under the same key could probably decrypt all messages!
[1] https://projects.lukehaas.me/runjs/images/runjs3.png
[2] https://nodejs.org/api/crypto.html#crypto_crypto_createciphe...
Instead of linking to proof about how right you are, since you obviously are, perhaps next time you could link to resources for us plebs to stay up-to-date. How do you keep tabs on "all the things" like this?
/shrug just my two cents.
The principle here is explained, at least partially: if you don't use a random IV for every message, you're not secure. So if the API you're using doesn't let you specify the IV, or doesn't default to a random IV that leaves you with undecipherable blocks if you don't fetch its assigned value, you know it's wrong. It's good info.
I think it's akin to a family physician saying, "this is best left to the surgeons."
Don't be fooled that just because you can write code, you can do crypto. But also, you can learn and you can also completely mess around in a safe, non-production environment.
Maybe my analogy is a bit weak.
I'd argue that in most cases not using crypto is better than using subtly broken crypto. At least users aren't deluded into thinking it's secure, and can take that into consideration when using (or not using) the system.
Whoever says this, whoever doesn't put in the hard yards to actually get good at cryptography, who is content with hugely flawed crypto — well, they shouldn't be in crypto in the first place.
And those unable to take constructive criticism, I don't know if they should be in real life.
If you used it and need to switch to the new API but be able to decrypt old stuff, here's some code to get the IV that the deprecated API actually derives, so you can use it with the new API: https://gist.github.com/bnoordhuis/2de2766d3d3a47ebe41aaaec7...
https://vikingvpn.com/blogs/security/visualizing-weak-encryp...
You suggest we hire a cryptographer every time we need something secured?
I mean, come on, this is ridiculous. The code quoted does not implement encryption, it invokes encryption. The AES algorithm being invoked, I expect, was written by proper cryptographers.
The reason this code is insecure is that the API is a piece of shit.
Most standard crypto modules have calls of the form
encrypt(algorithmName, arg, arg)
This is shit design and we can blame the cryptographers. It doesn't have to be this way.
Some languages and libraries get it right, here and there. Eg PHP doesn't just expose a way to call bcrypt, but also has two functions password_hash and password_hash_verify. These implement all the best practices, with seeds, the right algorithm parameters, keeping the ability to rehash in the future, etc.
We need similar APIs for symmetric and asymmetric encryption, for common use cases, or this madness is simply going to continue. Cryptographers, please get your act together. Job safety is nice, but a secure internet is nicer. Please make it easy for morons like me to use crypto right.
I mean, I don't even know what the different considerations are so I can't design these functions right, so please consider the spirit of the following proposal and not the details.
What about a function like encrypt_symmetric_for_single_user(payload, userid, key) which takes care of picking the right algorithm, doing the right dance with keys and nonces and whatnot? Or maybe functions need to include naming like encrypt_for_sending_once and encrypt_for_storing_long? My understanding is that you want different crypto in such cases, right? I'm sure better cryptographers than me can immediately see what I'm doing wrong here, but you catch the gist right? Why can't this be made easier? Why do we at the same time, collectively, shame everyone who gets security wrong and make it so unnecessarily hard for people to get right?
Is a crypto library designed to do exactly this, have a sensible API that does not expose any internal details for misuse, and generally gives you only one way to do things based on best practice algorithms.
It's got some big names behind it, and has probably quite mature since it's been going for several years.
There is also a popular fork, libsodium: https://libsodium.gitbook.io/doc/, which I think is more portable.
Also the documentation does not mention much in the way of how to _use_ the library. Do I send the nonce along with the ciphertext? Do I need to authenticate the nonce as well, then? To me it looks like NaCl and libsodium are still very much written by and for cryptographers.
Eg, many functions take nonces. Correct me if I'm wrong, but why can't they generate those nonces for me? Return a struct with the ciphertext and the nonce? Or have a make_nonce function generate a Nonce struct and only accepting that instead of a string?
I recognize that some of crypto, especially much other stuff than password hashing, is just intrinsically hard. But the APIs should expose only this intrinsic hardness and design the rest simply so you can't use it wrong. It's the exact same critique as a database client library that makes passing data separately harder than putting them right inside the query string (eg PHP's original mysql_query). Those are crap APIs and crypto APIs that let me screw up without even so much as a warning are also crap APIs.
Finally, to get into some classic HN style bikeshedding: 'NaCl (pronounced "salt")', really? So the idea is that when Bob recommends that Alice "just use salt", she understands that Bob means NaCl and not "just use a salt", the much more probable and totally wrong interpretation. Nonsense like this does not give me much faith that a library is designed for real world use by normal engineers.
I'd still love a library at a higher level of abstraction like I described above, but nevertheless I think this is cool.
[0] https://download.libsodium.org/doc/secret-key_cryptography/a...
I also wrote one for Graphviz (which outputs to an SVG buffer), and sometimes I'll put the output from the JS playground in `play-graphviz` mode so I can see real-time graph output from JS (by writing code to print dot graphs). ATM I don't know any other tools that can do that sort of thing, let alone compose independent ones to that end. Long live Emacs!
[0] https://bitbucket.org/gavinpc/play-modes/src/default/js-play... (There is an odd bug in OSX where the first character of the input is eaten, so I always begin these "playgrounds" with "/// playing with <whatever>". There are some other oddities which I should document.)
On the other hand, want to add an icon to your Windows app from a Mac? Jump down the rabbit hole of installing Wine and other dependencies and watch it spend minutes trying to invoke rc-edit.exe on Mac to make it work.
Some use cases :
- Coding interview
- Stack Overflow answers playground
- Instead of "node -pe ..."
i grew up with environments like QBasic and TurboPascal. they had everything you needed to learn and master specific languages? all in one package.
JavaScript is so lucky to have such easy integration with the electron stack. and with all the bad rap electron apps have been getting, this is just 160MB unzipped. the closest we have for Python is the mu editor. that editor is half a Gb unzipped!!
also, could it be that adding more features and library would make the size go up? who knows? anyways, looks good.
for refernce, on win 10: whatsapp - 200+mb and 4 processes. slack - 325mb and 5 processes.
Well that's what you get when the "solution" is to embed a webserver, a browser, a native executable to show that browser, and the server runs Node...
The solution is simple, stop shoving square pegs in round holes, and learn an appropriate language rather than shoehorn JS everywhere.
Being that this app's sole purpose is to evaluate JS, this may be a situation where JS isn't being shoehorned
There's plenty of ide-libraries in other languages to replace the one used by runjs.
To me it would make sense to build a real desktop application and bundle whatever JS engine you want to use, pipe and process the output as any other application.
You'd end up with a much smaller application (Download size), more resource-efficient, and less reliance on things like the bundled browser.
None of these things I care about. I care about whether or not it serves a purpose to me. If it does, I'll use it. If it doesn't, I won't. You might have other priorities and that's your prerogative.
A solution to reduce the size could be to ship the Electron runtime similar to .NET, etc.
However, PWA's are probably going to be the best bet going forward.
Interesting. Is it in some kind of sandbox, or can I accidentally remove files, etc?
Edit: Oh, it's an ios app?
Prior to that I was using a very cheap but sturdy Samsung with Linux on it.
On the Desktop I run Linux and Windows (only for Steam every now and then).
It is however surprisingly slow to execute the code on my machine. At first I thought it was the auto run delay, but even when running it manually it takes ≈ 0.9 seconds. Not really a problem, but I expected it to be quicker.
Sadly, it hasn't been updated in years.
let x = 2; for (let y=0; y < 10; x++){ console.log(x) } x
- for Javascript
- only for Mac
- evaluates JS as you type
?
YOUR AMIGA IS ALIVE. BUT IT IS INFECTED BY A VIRUS.
Thanks for the nostalgica.
If you ever decide to make it available in the browser, I will try it.
This reminds me of before 2010, when we though web apps will eat the world.
Have you been living under a rock? Mobile apps have taken over since where the action is (on mobile), and even on the desktop downloaded apps are doing just fine (even if some use web technologies like Electron).
What a weird world this is.