sjcl icon indicating copy to clipboard operation
sjcl copied to clipboard

The size of the IV for CCM and GCM mode should be restricted

Open deckar01 opened this issue 10 years ago • 3 comments

While testing AES in CCM mode using sjcl I was unable to decrypt the resulting cipher text with an external library, because sjcl allowed me to use an invalid IV size.

The nonce (IV) must be between 7 and 13 octets (21 and 39 bits).

Valid values of L range between 2 octets and 8 octets
...
A nonce N of 15-L octets.

http://tools.ietf.org/html/rfc3610

~~GCM mode should have the same restriction, but I have not tested it.~~

deckar01 avatar Jul 02 '14 00:07 deckar01

http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/proposedmodes/gcm/gcm-spec.pdf

As per section 2.1:

•  An initialization vector IV , that can have any number of bits between 1 and 2^64. For a fixed 
value of the key, each IV value must be distinct, but need not have equal lengths. 96-bit 
IV values can be processed more efficiently, so that length is recommended for situations in 
which efficiency is critical.

Are we sure the IV needs to be limited in this fashion for GCM? The given GCM vectors are all outside these bounds and thus with this restriction in place all the GCM tests fail. CBC is fine - I will push a commit and create a PR for that change this evening.

nstarke avatar Nov 04 '14 15:11 nstarke

After reading the NIST GCM spec, it definitely does not require the same restricted IV length. Sorry for the confusion.

Thanks for working on CCM mode!

deckar01 avatar Nov 04 '14 17:11 deckar01

sjcl.encrypt() broke because the default iv was 16 bytes:

  • https://github.com/bitwiseshiftleft/sjcl/blob/master/core/convenience.js#L28
var j = sjcl.json, p = j._add({ iv: sjcl.random.randomWords(4,0) },
                              j.defaults), tmp, prp, adata;

robocoder avatar Dec 23 '16 19:12 robocoder