Commit e8c08c9a36 ('EAP-FAST server: Fix
potential read-after-buffer (by one byte)') changed the while loop
design in a way that does not require the pos variable to be updated
anymore. Remove that unneeded code to clean up static analyzer warnings
about unused assignments.
Signed-off-by: Jouni Malinen <j@w1.fi>
This adds kek_len argument to aes_wrap() and aes_unwrap() functions and
allows AES to be initialized with 192 and 256 bit KEK in addition to
the previously supported 128 bit KEK.
The test vectors in test-aes.c are extended to cover all the test
vectors from RFC 3394.
Signed-off-by: Jouni Malinen <j@w1.fi>
The special PAC_OPAQUE_TYPE_PAD case did not skip incrementing of the
pos pointer and could result in one octet read-after-buffer when parsing
the PAC-Opaque data.
Signed-off-by: Jouni Malinen <j@w1.fi>
Reduce the amount of time keying material (MSK, EMSK, temporary private
data) remains in memory in EAP methods. This provides additional
protection should there be any issues that could expose process memory
to external observers.
Signed-off-by: Jouni Malinen <j@w1.fi>
This makes the implementation less likely to provide useful timing
information to potential attackers from comparisons of information
received from a remote device and private material known only by the
authorized devices.
Signed-off-by: Jouni Malinen <j@w1.fi>
Use size_t instead of int for storing and comparing the TLV length
against the remaining buffer length to make this easier for static
analyzers to understand.
Signed-off-by: Jouni Malinen <j@w1.fi>
This commit adds a new wrapper, random_get_bytes(), that is currently
defined to use os_get_random() as is. The places using
random_get_bytes() depend on the returned value being strong random
number, i.e., something that is infeasible for external device to
figure out. These values are used either directly as a key or as
nonces/challenges that are used as input for key derivation or
authentication.
The remaining direct uses of os_get_random() do not need as strong
random numbers to function correctly.
This indicates that the peer identity is associated with the
credential and will be required to match with the identity used
during authentication when the PAC is used (RFC 5422, 4.2.4).