-
Notifications
You must be signed in to change notification settings - Fork 198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add simple "zerobinpaste" cli tool #39
Conversation
I'm ok with including the nodejs base tool, as it is better than You can update the doc, I'll include that. Thanks a lot for all your However, my guts tells me that if the problem is that we use a a flaky Indeed, we probably want something that any language can handle easily Do you have something better than sjcl in mind, or maybe juste better Le sam. 20 avril 2013 19:42:36 CEST, Mike Kazantsev a écrit :
|
Will do wrt docs. And I'm afraid I have no experience with js-based crypto - heard in the news that web-crypt-api is on the horizon, but I guess it shouldn't be relied upon yet. I don't think that sjcl is that bad solution, and the most evil thing I see there is using it's "convenience.js" lib:
Now, how convenience.js uses these is imho is the problem, and one solution would be to ditch it and instead of old obscure "what is this?" json return new one, like:
That provides all the parameters as per RFC. I'm fairly certain that PBKDF2 is only used in these convenience functions to bump work-factor in case of low-entropy keys like "admin123", for - well - convenience. In any case, I'd propose to just ditch PBKDF2 entirely and just use AES-CCM directly with an explicit set of parameters which will be returned in output JSON. That should work with newer openssl and isn't that hard to implement by hand (provided just aes primitive) (e.g. this code). Using OCB2 in a similar direct way might be better, as it seem to be more widespread, but I didn't looked at that closely enough. Ditching all these block-chaining stuff and going for just stream cipher (e.g. XSalsa20), where you need just a (for salsa) 64b nonce, 256b key and whatever-length plaintext - no padding, modes and such - might be another solution. Maybe some ultra-fast public-key ec stuff like ed25519 would also be a good option, but I'd rather trust some stanford-aes thing than hip js non-djb implementation of that. So in summary, I think just going for aes-ccm or aes-ocb2 with explicit parameters from sjcl.js is a good enough option and not ditching sjcl would allow for compatibility with old pastes that are still around. |
Ok. It's a big decision so I'll need time to process that. I'm going to Le dim. 21 avril 2013 08:55:51 CEST, Mike Kazantsev a écrit :
|
Pushed the doc updates, please check if readthedocs handles these correctly (especially unsure about internal links / new rst there). |
Wrt crypto - cryptocat seem to have fairly well-exposed and apparently useable ed25519 implementation, which has python-ed25519 module, supported by pycryptopp, libsodium, rbnacl, reference djb's NaCl lib and seem to be fairly trendy and popular in that regard. I plan to take a stab at replacing sjcl with that thing with much shorter native urls (url shorteners leak keys to google of all things), interoperability and smple black-box implementation being the main goals. Should be fairly simple if js from cryptocat will "just work", but I plan to also make paste ids shorter (or rather have configurable length) - even 6 base64 chars should provide 7e10 combinations - which is not remotely close to number of pastes on even most popular sites (guessing). ed25519 should allow for much shorter key part as well. |
Add simple "zerobinpaste" cli tool
I merged and will test read the doc. For the crypto issue, I open #40. |
I translated the doc to french. Thanks a lot, you took a lot of time for this. |
From a security point of view using using aes256/chacha20 instead of using a hybrid scheme with ed25519 is always preferred. Currently the best recommendation would be to use chacha20poly1305. But as this is quite "new", xsalsa20poly1305 would be the more compatible choice regarding different implementations. |
Not sure how you'd feel about node-based js tool in the python app repo, but the first thing I needed to actually use the paste is to be able to do
grep stuff file.log | zerobinpaste | xclip
, so wrote the thing.Initially I've started writing it in python (that's why I looked into encryption and found #38), but quickly discovered that:
So the sanest way seem to be to reuse exactly the same weird code to reliably produce decryptable pastes, hence nodejs tool.
It should be easily buildable via
make
in "tools" path and produces self-sufficient js file, requiring only node.js to run.make ugly
can be used to also npm-install/run uglifyjs on it for 48K -> 32K size shrink.CLI:
Feel free to just drop PR if you don't care about the thing (and don't want to sort out bugs filed against it), I'll be maintaining it for myself anyway.
Otherwise feel free to drop an ack and I'll go ahead and update the docs about it as well.