Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am using the Stanford Javascript Crypto library and i'd like more information about it.

1.) I have an ASCII text and a random 128-bit key. I want to concat those two things, so I convert the ASCII text into hex and then to a BitArray.
Example : var text="kheil" ; var textHex=asc2hex(text);var textBitArray= sjcl.codec.hex.toBits(textHex);
I get the following BitArray : 1802003817,8797904961536.
What is worrying me is the last number, why is it longer ? It's more than a 32-bit number. With some ASCII text, it's fine I get a BitArray with 32-bit numbers but with some others I get this kind of suff, is it normal ? And If I concat it with a random number : -96822511,1783357814,2009621896,-1425360948, I get : 1802003817,1828338331,292178913,1987561573,-2002056521,8795220606976 which is not a good concatenation no ? My guess is that the text is not a multiple of 32-bits, but how to get a good BitArray for any text ?

2.) Also to compute a random 128-bit key I use sjcl.random.randomWord(4,0), is it an efficient function to compute a random key ? I read somewhere that I should not use 0 as paranoia, or it's necessary to call startCollector() to get entropy. I am bit confuse about that, could any one explain that to me ?

Thank you !

share|improve this question
    
I think I have understood the first point. It looks like sjcl is adding a bit 1 at the beginning of the last 32 bits in some case. Using my example : 'kheil' is equal to 01101011011010000110010101101001 ; 01101100 and 1802003817 ; 8797904961536 is equal to 1101011011010000110010101101001 ; 10000000000001101100000000000000000000000000. So finally, the BitArray seems right no ? –  Kheil Jul 4 '13 at 1:48

2 Answers 2

up vote 4 down vote accepted

Without looking at the exact numbers, let me give some pointers as to why this is happening:

  1. According to the docs, sometimes it will use some extra bits to store additional information (namely, the actual number of bytes):

    Most of our crypto primitives operate on arrays of 4-byte words internally, but many of them can take arguments that are not a multiple of 4 bytes. This library encodes arrays of bits (whose size need not be a multiple of 8 bits) as arrays of 32-bit words. The bits are packed, big-endian, into an array of words, 32 bits at a time. Since the words are double-precision floating point numbers, they fit some extra data. We use this (in a private, possibly-changing manner) to encode the number of bits actually present in the last word of the array.

    Because bitwise ops clear this out-of-band data, these arrays can be passed to ciphers like AES which want arrays of words.

    That probably accounts for the the extra bit that's being appended, and also explains why concatenating two BitArrays will not simply concatenate the word arrays, as you seem to be expecting. If the first one had actually a multiple of 4 bytes, then yes, that's what would happen.

  2. If I remember correctly, SJCL will try to use the crypto functionality of modern browsers to create its random number generator, falling back to a custom made one (which uses mouse movement, keystrokes, etc to generate additional entropy to be combined with a [non-cryptographic] PRNG). That means in modern browser it's unimportant whether you set the paranoia or not. On older browsers (or ones that does not support crypto) then you really must put the collectors to work if you plan to use algorithms that depend on a CSPRNG. I'd help you more, but I've never used that functionality myself, so I can only direct you to the docs.

P.S. US-ASCII is a subset of UTF-8, so you don't need to convert to Hex first and then to a BitArray. Just use sjcl.codec.utf8String.toBits(str). (on second thought, how do you know your text is really ASCII? SJCL [normally] runs in a browser... Better be safe, and make your code Unicode-compliant)

share|improve this answer

The reason the BitArray contains ints >32bits is that codec.hex.toBits assumes that the supplied hex string has a length that is a multiple of 8. Presumably this is because the codec is intended for internal use but I thought I would mention it here because I found no indication of this limitation in any other documentation or discussion of SJCL.

To run arbitrary text through toBits you could zero pad the front of the hex string representation to end up with a hex string of length%8 = 0.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.