Amazing-Mirror/fragattacks
1
0
Fork 0
mirror of https://github.com/vanhoefm/fragattacks.git synced 2024-11-26 09:18:24 -05:00
Code Issues Projects Releases Wiki Activity
ceb34f250a
fragattacks/src/crypto/random.h

35 lines
1.0 KiB
C
Raw Normal View History

Annotate places depending on strong random numbers 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.
2010-11-23 18:05:20 -05:00
/*
* Random number generator
random: Read /dev/random in the background with eloop read socket This makes it more likely to be able to fetch the 20 octet seed from /dev/random in cases where other programs may also be competing for this.
2011-03-22 17:15:00 -04:00
* Copyright (c) 2010-2011, Jouni Malinen <j@w1.fi>
Annotate places depending on strong random numbers 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.
2010-11-23 18:05:20 -05:00
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
* Alternatively, this software may be distributed under the terms of BSD
* license.
*
* See README and COPYING for more details.
*/
#ifndef RANDOM_H
#define RANDOM_H
Maintain internal entropy pool for augmenting random number generation By default, make hostapd and wpa_supplicant maintain an internal entropy pool that is fed with following information: hostapd: - Probe Request frames (timing, RSSI) - Association events (timing) - SNonce from Supplicants wpa_supplicant: - Scan results (timing, signal/noise) - Association events (timing) The internal pool is used to augment the random numbers generated with the OS mechanism (os_get_random()). While the internal implementation is not expected to be very strong due to limited amount of generic (non-platform specific) information to feed the pool, this may strengthen key derivation on some devices that are not configured to provide strong random numbers through os_get_random() (e.g., /dev/urandom on Linux/BSD). This new mechanism is not supposed to replace proper OS provided random number generation mechanism. The OS mechanism needs to be initialized properly (e.g., hw random number generator, maintaining entropy pool over reboots, etc.) for any of the security assumptions to hold. If the os_get_random() is known to provide strong ramdom data (e.g., on Linux/BSD, the board in question is known to have reliable source of random data from /dev/urandom), the internal hostapd random pool can be disabled. This will save some in binary size and CPU use. However, this should only be considered for builds that are known to be used on devices that meet the requirements described above. The internal pool is disabled by adding CONFIG_NO_RANDOM_POOL=y to the .config file.
2010-11-23 18:29:40 -05:00
#ifdef CONFIG_NO_RANDOM_POOL
random: Read /dev/random in the background with eloop read socket This makes it more likely to be able to fetch the 20 octet seed from /dev/random in cases where other programs may also be competing for this.
2011-03-22 17:15:00 -04:00
#define random_init() do { } while (0)
#define random_deinit() do { } while (0)
Maintain internal entropy pool for augmenting random number generation By default, make hostapd and wpa_supplicant maintain an internal entropy pool that is fed with following information: hostapd: - Probe Request frames (timing, RSSI) - Association events (timing) - SNonce from Supplicants wpa_supplicant: - Scan results (timing, signal/noise) - Association events (timing) The internal pool is used to augment the random numbers generated with the OS mechanism (os_get_random()). While the internal implementation is not expected to be very strong due to limited amount of generic (non-platform specific) information to feed the pool, this may strengthen key derivation on some devices that are not configured to provide strong random numbers through os_get_random() (e.g., /dev/urandom on Linux/BSD). This new mechanism is not supposed to replace proper OS provided random number generation mechanism. The OS mechanism needs to be initialized properly (e.g., hw random number generator, maintaining entropy pool over reboots, etc.) for any of the security assumptions to hold. If the os_get_random() is known to provide strong ramdom data (e.g., on Linux/BSD, the board in question is known to have reliable source of random data from /dev/urandom), the internal hostapd random pool can be disabled. This will save some in binary size and CPU use. However, this should only be considered for builds that are known to be used on devices that meet the requirements described above. The internal pool is disabled by adding CONFIG_NO_RANDOM_POOL=y to the .config file.
2010-11-23 18:29:40 -05:00
#define random_add_randomness(b, l) do { } while (0)
Annotate places depending on strong random numbers 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.
2010-11-23 18:05:20 -05:00
#define random_get_bytes(b, l) os_get_random((b), (l))
hostapd: Verify availability of random data when using WPA/WPA2 On Linux, verify that the kernel entropy pool is capable of providing strong random data before allowing WPA/WPA2 connection to be established. If 20 bytes of data cannot be read from /dev/random, force first two 4-way handshakes to fail while collecting entropy into the internal pool in hostapd. After that, give up on /dev/random and allow the AP to function based on the combination of /dev/urandom and whatever data has been collected into the internal entropy pool.
2010-11-24 06:08:03 -05:00
#define random_pool_ready() 1
#define random_mark_pool_ready() do { } while (0)
Maintain internal entropy pool for augmenting random number generation By default, make hostapd and wpa_supplicant maintain an internal entropy pool that is fed with following information: hostapd: - Probe Request frames (timing, RSSI) - Association events (timing) - SNonce from Supplicants wpa_supplicant: - Scan results (timing, signal/noise) - Association events (timing) The internal pool is used to augment the random numbers generated with the OS mechanism (os_get_random()). While the internal implementation is not expected to be very strong due to limited amount of generic (non-platform specific) information to feed the pool, this may strengthen key derivation on some devices that are not configured to provide strong random numbers through os_get_random() (e.g., /dev/urandom on Linux/BSD). This new mechanism is not supposed to replace proper OS provided random number generation mechanism. The OS mechanism needs to be initialized properly (e.g., hw random number generator, maintaining entropy pool over reboots, etc.) for any of the security assumptions to hold. If the os_get_random() is known to provide strong ramdom data (e.g., on Linux/BSD, the board in question is known to have reliable source of random data from /dev/urandom), the internal hostapd random pool can be disabled. This will save some in binary size and CPU use. However, this should only be considered for builds that are known to be used on devices that meet the requirements described above. The internal pool is disabled by adding CONFIG_NO_RANDOM_POOL=y to the .config file.
2010-11-23 18:29:40 -05:00
#else /* CONFIG_NO_RANDOM_POOL */
random: Read /dev/random in the background with eloop read socket This makes it more likely to be able to fetch the 20 octet seed from /dev/random in cases where other programs may also be competing for this.
2011-03-22 17:15:00 -04:00
void random_init(void);
void random_deinit(void);
Maintain internal entropy pool for augmenting random number generation By default, make hostapd and wpa_supplicant maintain an internal entropy pool that is fed with following information: hostapd: - Probe Request frames (timing, RSSI) - Association events (timing) - SNonce from Supplicants wpa_supplicant: - Scan results (timing, signal/noise) - Association events (timing) The internal pool is used to augment the random numbers generated with the OS mechanism (os_get_random()). While the internal implementation is not expected to be very strong due to limited amount of generic (non-platform specific) information to feed the pool, this may strengthen key derivation on some devices that are not configured to provide strong random numbers through os_get_random() (e.g., /dev/urandom on Linux/BSD). This new mechanism is not supposed to replace proper OS provided random number generation mechanism. The OS mechanism needs to be initialized properly (e.g., hw random number generator, maintaining entropy pool over reboots, etc.) for any of the security assumptions to hold. If the os_get_random() is known to provide strong ramdom data (e.g., on Linux/BSD, the board in question is known to have reliable source of random data from /dev/urandom), the internal hostapd random pool can be disabled. This will save some in binary size and CPU use. However, this should only be considered for builds that are known to be used on devices that meet the requirements described above. The internal pool is disabled by adding CONFIG_NO_RANDOM_POOL=y to the .config file.
2010-11-23 18:29:40 -05:00
void random_add_randomness(const void *buf, size_t len);
int random_get_bytes(void *buf, size_t len);
hostapd: Verify availability of random data when using WPA/WPA2 On Linux, verify that the kernel entropy pool is capable of providing strong random data before allowing WPA/WPA2 connection to be established. If 20 bytes of data cannot be read from /dev/random, force first two 4-way handshakes to fail while collecting entropy into the internal pool in hostapd. After that, give up on /dev/random and allow the AP to function based on the combination of /dev/urandom and whatever data has been collected into the internal entropy pool.
2010-11-24 06:08:03 -05:00
int random_pool_ready(void);
void random_mark_pool_ready(void);
Maintain internal entropy pool for augmenting random number generation By default, make hostapd and wpa_supplicant maintain an internal entropy pool that is fed with following information: hostapd: - Probe Request frames (timing, RSSI) - Association events (timing) - SNonce from Supplicants wpa_supplicant: - Scan results (timing, signal/noise) - Association events (timing) The internal pool is used to augment the random numbers generated with the OS mechanism (os_get_random()). While the internal implementation is not expected to be very strong due to limited amount of generic (non-platform specific) information to feed the pool, this may strengthen key derivation on some devices that are not configured to provide strong random numbers through os_get_random() (e.g., /dev/urandom on Linux/BSD). This new mechanism is not supposed to replace proper OS provided random number generation mechanism. The OS mechanism needs to be initialized properly (e.g., hw random number generator, maintaining entropy pool over reboots, etc.) for any of the security assumptions to hold. If the os_get_random() is known to provide strong ramdom data (e.g., on Linux/BSD, the board in question is known to have reliable source of random data from /dev/urandom), the internal hostapd random pool can be disabled. This will save some in binary size and CPU use. However, this should only be considered for builds that are known to be used on devices that meet the requirements described above. The internal pool is disabled by adding CONFIG_NO_RANDOM_POOL=y to the .config file.
2010-11-23 18:29:40 -05:00
#endif /* CONFIG_NO_RANDOM_POOL */
Annotate places depending on strong random numbers 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.
2010-11-23 18:05:20 -05:00
#endif /* RANDOM_H */
Reference in New Issue Copy Permalink