Description of problem:
It looks as though intel_aes_decrypt_cbc_256() doesn't work right when the input and output buffers are the same, though this appears to be something that PK11_CipherOp (which eventually calls this function, on processors that support it) is expected to be able to handle.
Version-Release number of selected component (if applicable):
Always, provided you're on a 64-bit processor with native AES instruction support (the "flags:" line in /proc/cpuinfo will include "aes"). I've tested this on an i5 processor and also had it checked on an i7.
Steps to Reproduce:
1. Run reproducer with the "-i" flag, which will cause it to use the same buffer for input and output and default to a 256-bit key.
"Encrypted/recovered 32 bytes."
While NSS itself doesn't seem to trigger this behavior, the nascent support for using NSS as the backend for krb5's libk5crypto does.
Created attachment 502120 [details]
gcc -o aest aest.c `pkg-config --cflags --libs nss`
./aest -i (uses in-place encryption, errors out)
env NSS_DISABLE_HW_AES=1 ./aest -i (uses unoptimized implementation, no error)
./aest (doesn't do encryption in place, no error)
nss-softokn-3.12.10-2.fc15 has been submitted as an update for Fedora 15.
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nss-softokn-3.12.10-2.fc15'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
nss-softokn-3.12.10-2.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.