C_DeriveKey() error with leading zero bytes about softhsmv2 HOT 4 CLOSED

Just thought I'd add the probability of finding 0 times 0x00 on accident, to make sure it really is a bug:

The question how often a certain value occurs is a Bernouilli experiment with n=10000 and p=1/256 so the chance of never getting a certain value (like 0x00) is

PR (X<=0)
= \sum_{i=0}^0 (n \over i) * p^i * (1-p)^(n-i)
= (n \over 0) * p^0 * (1-p)^n
= 1 * 1 * (255/256)^10000
= .00000000000000001004

which is about 1 in 2^56. Since my program therefore is a pretty certain test :) let me know if you want me to test drive a fix! If you prefer to check for yourself, you could detect the sudden absense of the ^Failed pattern in the output (now ~40 times after setting NITER=10000 in test_srp11.c and then running test_srp11)

from softhsmv2.

Truncation should remove bytes from the leading end of the secret value for CKM_DH_PKCS_DERIVE and CKM_ECDH1_DERIVE. But we are removing the trailing bytes. Have a fix for this.

Have also found issues in both the Botan and OpenSSL code in SoftHSM. Should I append leading zeroes or should the derived key be variable length (before truncation)?

from softhsmv2.

Does it work better with #178 ?

from softhsmv2.

Victory!

shell$ ./test_srp11 > /tmp/x
shell$ grep ^Failed /tmp/x | wc -l
0

The bug is gone, so the end result is there (used to hit 40 per run of 10000). So, what has happened?

shell$ grep 'p11_mod_exp() returns 512 bytes' /tmp/x | wc -l
10000
shell$ grep 'p11_mod_exp() returns 511 bytes' /tmp/x | wc -l
0

The change is not in the length of the result, so it must be in the leading zero bytes (had to be either/or):

shell$ for firstbyte in 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f; do echo -n "Occurrences of $firstbyte: " ; grep "p11_mod_exp() returns 512 bytes $firstbyte" /tmp/x | wc -l ; done
Occurrences of 0x00: 47
Occurrences of 0x01: 35
Occurrences of 0x02: 36
Occurrences of 0x03: 38
Occurrences of 0x04: 36
Occurrences of 0x05: 37
Occurrences of 0x06: 45
Occurrences of 0x07: 32
Occurrences of 0x08: 39
Occurrences of 0x09: 56
Occurrences of 0x0a: 38
Occurrences of 0x0b: 33
Occurrences of 0x0c: 40
Occurrences of 0x0d: 34
Occurrences of 0x0e: 46
Occurrences of 0x0f: 53

which is indeed what was needed.

I don't know whether reducing the response size is better or allowing leading zero bytes -- either works in a proper program -- and I don't know if PKCS #11 has anything to say on this point (given the indirection of generating a key, then extracting it) so I didn't respond to your self-reflective question on that point.

Thanks Rickard! The chance of it still being buggy now is .00000000000000001004 which to me is a strong enough proof that you've done an excellent job, once again :)

from softhsmv2.