The crypto_ptk was hard coded for 16 byte KCK/KEK. Depending on the
AKM these can be up to 32 bytes. This changes completely removes the
crypto_ptk struct and adds getters to the handshake object for the
kck and kek. Like before the PTK is derived into a continuous buffer,
and the kck/kek getters take care of returning the proper key offset
depending on AKM.
To allow for larger than 16 byte keys aes_unwrap needed to be
modified to take the kek length.
The RFC (5869) for this implementation defines two functions,
HKDF-Extract and HKDF-Expand. The existing 'hkdf_256' was implementing
the Extract function, so it was renamed appropriately. The name was
changed for consistency when the Expand function will be added in the
future.
The "H" function used by SAE and EAP-PWD was effectively the same
function, EAP-PWD just used a zero key for its calls. This removes
the duplicate implementations and merges them into crypto.c as
"hkdf_256".
Since EAP-PWD always uses a zero'ed key, passing in a NULL key to
hkdf_256 will actually use a 32 byte zero'ed array as the key. This
avoids the need for EAP-PWD to store or create a zero'ed key for
every call.
Both the original "H" functions never called va_end, so that was
added to hkdf_256.
==40686== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s)
==40686== at 0x5147037: sendmsg (in /usr/lib64/libc-2.24.so)
==40686== by 0x43957C: operate_cipher (cipher.c:354)
==40686== by 0x439C18: l_cipher_decrypt (cipher.c:415)
==40686== by 0x40FAB8: arc4_skip (crypto.c:181)
Initialize the skip buffer to 0s. This isn't strictly necessary, but
hides the above valgrind warning.
The aim of arc4 skip is simply to seed some data into the RC4 cipher so
it makes it harder for the attacker to decrypt. This 'initialization'
doesn't really care what data is fed.
