Documentation seem to be incorrect wrt actual cipher being used

[mk-fg]

Current behavior.js seem to use sjcl.encrypt(key, content) with no extra parameters and sjcl code (which seem to match the code in minified version - same default-parameters line can be found there: {v:1,iter:1E3,ks:128,ts:64,mode:"ccm",adata:"",cipher:"aes"}) uses standard AES as in "Rijndael with 128-bit block size" (in CCM mode plus PBKDF2 with 1k iterations for key).

Yet all docs seem to advertise that AES256 is used instead, I'm confused. Am I reading the code or docs wrong?

If not, maybe it'd be better to either correct documentation or change the cipher actually used (might be more difficult, as it will break all previous pastes)?

[mk-fg]

In fact, sjcl.mode docs for both supported block-to-stream modes (ccm and ocb2) explicitly state that:

Parameters:
  {Object} prf
    The pseudorandom function. It must have a block size of 16 bytes.

...for every .encrypt() and .decrypt() method, which definitely rules out AES256, as it has 32-byte block size.

Edit: to correct myself - there seem to be source for other modes (like gcm), which are not mentioned in the docs.

[sametmax]

If think documentation is incorrect. I don't recall changing the default in the minified file and the plain source code clearly state using the default parameter.

What you say is confirmed by:

http://stackoverflow.com/questions/13705850/is-sjcl-encrypt-using-aes-or-sha256

I'm ok with 128 bits, as the purpose of zerobin is to provide me with the reasonable assumption that I can't read all the paste I host given the time it would take me just to read one.

But it does need fixing, and above all, we need to add a way to declare the encoding strength in the settings file. And It need to be stored with each paste, so decoding always knows what to use, and if nothing is declared, it should use the current one.

This will help with people :

• needing a stronger encryption
• migrating from one type to another

We could even offer several encryption algorithmes.

I have no time for it now, but I'll look into it some months if nobody provides a PL for it in the meantime.

[mk-fg]

Indeed, might be worth adding that choice.

Stable sjcl (as mentioned, code for other stuff is there, but it's probably not safe to use it yet) provides quite limited number of options - aes-ccm or aes-ocb2 with tweakable number of pbkdf2 iterations for the key.

It should be possible to keep these options in fragment along with the key, though for "migrating from one type to another" option, it probably should be done server-side, so that server knows which js-crypto-implementation to serve (a lot of encryption paramers - and maybe bugs - is hard-coded into sjcl-0.8 for example) along with the ciphertext.