Hi ! First of all, thank you for your time.
Wan-Teh Chang a écrit :
2009/12/2 Gregory BELLIER <gregory.bell...@gmail.com>:
Examples :
- For Camellia at the end of camellia_encryptCBC(CamelliaContext *cx, ...) :
lastblock = output;
memcpy(cx->iv, lastblock, CAMELLIA_BLOCK_SIZE);
return SECSuccess;
We save lastblock in cx->iv (at line 1541) so that it will become
lastblock in the next invocation of camellia_encryptCBC (at line 1522):
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/camellia.c&rev=1.2&mark=1511,1522,1541#1511
- For SEED at the end of the encryption part in SEED_cbc_encrypt(unsigned
char ivec[SEED_BLOCK_SIZE], ...) :
iv = out;
memcpy(ivec, iv, SEED_BLOCK_SIZE);
(no return here because this function returns void)
Same reason here:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/seed.c&rev=1.3&mark=466,472,497#466
ivec is equivalent to cx->iv for camellia_encryptCBC.
iv is equivalent to lastblock for camellia_encryptCBC.
Agreed.
Do we use this last block somewhere else in NSS to justify this backup ?
Yes, this last block needs to be saved for the next invocation
of the CBC encryption function.
Ok, so now I understand better. The IV is a data which needs to be
changed after each operation. However, I just asked a colleague who
knows better than me and he's surprised that the new IV is the
lastblock. It brings 2 concerns :
1- The new IV is supposed to be random in this case, it is not. Should
we be concerned about that ?
2- In the case of SEED, after decryption in the else part, the new IV is
a part of cleartext :
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/seed.c&mark=521,537,542
Are these 2 points serious ?
(off-topic: About the SEED cipher : why do they encrypt and decrypt in the
same function called encrypt ???)
I don't know why. I think we can change that. The encryption
and decryption code in SEED_cbc_encrypt is completely disjoint
(the 'tmp' local variable is only used in decryption).
Agreed.
Would you like to submit a patch to separate the encryption
and decryption code in SEED_cbc_encrypt into two functions?
And SEED_ecb_encrypt can simply be deleted and replaced
by direct calls to SEED_encrypt and SEED_decrypt.
Wan-Teh
I don't mind providing a patch if in the end with its review, I can have
the guarantee that there's no security flaw. Moreover, in the SEED
algorithm, I don't understand why a var is declared as a "const" whereas
it is modified later in the code :
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/freebl/seed.c&mark=472,480
Other question about the decryption part of the algorithm:
is it really needed to test " if (in != out) " and then to do a " else "
? Couldn't we just use the " in != out " part as the decryption
algorithm and forget/delete the " else " part ?
Thanks again.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
