Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add simple "zerobinpaste" cli tool #39
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
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
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.
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 :
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.
added a commit
this pull request
Apr 22, 2013
referenced this pull request
Apr 22, 2013
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.