Reorder terms in a way that no invalid pointers are generated with
pos+len operations. end-pos is always defined (with a valid pos pointer)
while pos+len could end up pointing beyond the end pointer which would
be undefined behavior.
Signed-off-by: Jouni Malinen <j@w1.fi>
It does not look likely that the old DSA design would be added into the
internal TLS implement, so remove this otherwise dead code.
Signed-off-by: Jouni Malinen <j@w1.fi>
Add support for generating and verifying RFC 3447 RSASSA-PKCS1-v1_5
style DigestInfo for TLS v1.2 CertificateVerify. For now, this is
hardcoded to only support SHA256-based digest.
Signed-hostap: Jouni Malinen <j@w1.fi>
This patch fixes a problem I had when I tried to connect
an embedded system [wpa_supplicant, CONFIG_TLS=internal]
to my TLS secured network.
TLSv1: Send CertificateVerify
TLSv1: CertificateVerify hash - hexdump(len=36): ha .. ha
PKCS #1: pkcs1_generate_encryption_block - Invalid buffer lengths \
(modlen=512 outlen=454 inlen=36)
It turned out that a fixed 1000 byte message buffer was just
a little bit too small for the 4096 bit RSA certificates
I'm using.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
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.
Clean up the internal TLS implementation by removing conditional
build blocks for (mostly) EAP-FAST specific functionality. This
will increase the size a big for non-EAP-FAST builds, but is quite
helpful in making src/tls/libtls.a with single build options. If
the potential size reduction is considered significant in the future,
this can be reconsider with a more library compatible way (e.g.,
external file with registration function, etc.).
In addition, start ordering header file includes to be in more
consistent order: system header files, src/utils, src/*, same
directory as the *.c file.
